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Abstract 


This  report  provides  an  in-depth  assessment  of  the  U.S.  CASE  technol- 
ogy market  with  a  projection  of  developments  and  growth  over  the  next 
five  years.  CASE  technology  exploded  on  the  market  in  the  late  1980s 
and  since  has  faced  continual  challenges  in  achieving  the  level  of  success 
and  acceptance  that  early  response  suggested. 

INPUT,  in  its  second  assessment  of  this  important  market,  positions  the 
CASE  market  within  the  U.S.  information  services  industry,  provides  an 
analysis  of  the  impact  of  IBM's  AD/Cycle,  describes  the  current  perspec- 
tives on  CASE  in  the  information  systems  function,  sizes  the  U.S.  mar- 
ket, and  analyzes  the  forces  driving  and  inhibiting  success.  CASE  con- 
tinues to  offer  significant  opportunity  to  strengthen  the  information 
services  industry  through  improvements  in  productivity,  systems  quality, 
and  systems  longevity.  This  analysis  provides  valuable  insights  to  both 
vendor  and  information  systems  executives  as  they  strive  to  achieve  the 
benefits  successful  CASE  implementation  offers. 

This  report  contains  106  pages  and  82  exhibits. 
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Introduction 


This  report  and  the  related  research  was  performed  as  part  of  INPUT'S 
Information  Systems  Program.  This  program  serves  the  management  of 
leading  vendors  in  the  information  services  industry  and  the  information 
systems  function  of  large  organizations. 

Throughout  this  report,  IS  refers  to  the  information  systems  functions  of 
corporations. 

A   

Scope  This  report  examines  developments  in  CASE  (computer-assisted  systems 

engineering)  which  involve  the  development  of  business  systems.  The 
main  focus  is  on  two  interrelated  issues: 

•  IS  departments'  requirements  and  plans 

•  Technology  issues  affecting  the  increased  use  and  effectiveness  of 
CASE 

Based  on  INPUT'S  analysis  of  requirements  and  technology,  INPUT  has 
developed  several  scenarios  on  CASE  growth  for  the  1991-1996  period. 
INPUT'S  forecast  is  for  the  size  of  the  CASE  product  market.  It  is 
currently  not  feasible  to  measure  the  separate  impact  of  CASE  on  other 
areas.  In  professional  services,  for  example,  the  amount  of  pure  CASE 
services  is  relatively  modest;  the  extent  to  which  CASE  permeates  other 
services  is  significant,  but  resistant  to  quantification.  However,  INPUT 
believes  that  the  rate  of  market  growth,  and  especially  the  development  of 
its  alternate  growth  scenarios,  represent  a  good  surrogate  for  the  growth 
of  overall  CASE  use. 

Section  C  of  this  chapter.  Definitions,  defines  in  more  detail  the  areas 
included  and  excluded  in  this  report. 
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Objectives 


This  report  will  address  the  following  issues: 


•  How  effective  within  corporations  has  CASE  been  to  date? 

•  How  will  applications  development  change  from  1991  to  1996? 

•  What  is  the  current  and  planned  use  of  CASE? 

•  What  are  the  most  serious  barriers  to  wider  CASE  use? 

•  How  important  are  technical  issues  generally  for  CASE  acceptance? 

•  What  impact  will  developments  in  re-engineering  have  on  CASE 
technology  and  CASE  use? 

•  What  are  the  "stages"  of  CASE? 

•  How  important  is  distributed  applications  development? 

•  What  are  the  "soft"  CASE  implementation  issues?  How  important  are 
they? 

•  How  large  is  the  CASE  product  market  likely  to  be  by  1996?  Under 
what  circumstances  will  it  be  larger  or  smaller? 

•  How  dominant  will  AD/Cycle  be?  What  effect  will  AD/Cycle  have  on 
users  and  other  vendors? 

•  What  impacts  will  CASE  have  on  application  software  companies? 

•  What  options  do  professional  services  firms  and  systems  integrators 
have  in  responding  to  CASE  developments? 


This  report  focuses  on  CASE  as  used  to  develop  business  applications. 
CASE,  in  this  context,  includes: 

•  Forward  engineering 

•  Re-engineering 

•  Repository  technology 

Exhibit  I-l  lays  out  the  major  components  of  CASE  and  their  relation- 
ships. 

Forward  engineering  has  traditionally  been  divided  into: 


c 


Definitions 


1.  Terms  Addressed  in  this  Report 
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•  Front-end  tools  for  performing  requirements,  analysis,  and  design  work 

•  Back-end  tools,  or  code  generators 


EXHIBIT  1-1 


CASE  Components 


Front  End 


Back  End 


Forward 
Engineering 


Requirements, 
Analysis,  Design  Tools 


Code 

Generators 


Application 


Re-engineering 


Re-use 


Reverse 
Engineering 


Generator 


L 


In  the  1980s  front-end  and  back-end  tools  were  generally  separate.  With 
the  advent  of  repository  technology,  this  has  begun  to  change  quickly. 

•  A  repository  (or  encyclopedia)  is  used  to  capture  requirements  and 
design  on  a  centralized  basis. 

•  The  repository  can  maintain  changes  and  serve  as  the  input  point  for 
code  generation. 

Chapter  IV  discusses  these  issues  in  more  depth. 

In  this  report  re-engineering  is  used  to  describe  the  entire  process  for 
taking  an  existing  application  and  either  re-using  the  logic  or  reverse- 
engineering  the  code.  These  differences  are  shown  in  Exhibit  1-2. 
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EXHIBIT  1-2 


Re-engineering  Options 

V.  Application  Code,  <^ 

^    Data  Structures  j 

Re-engineering  Process 

> 

Reverse- 

 X 

Options 

Engineered 

Re-used 

(One/Both) 

Application 

Application 

•  Stabilize  application 

•  Learn  data/process  logic 

^OUiim/dll  lllciy 

•  "Re-write" 

•  Help  populate  repository 

be  involved 

•  One-time/multiple 

•  Form  base  case  for 

changes 

fonward  engineering 

•  Short/long  life 

expectancy 

Attributes 

•  Restructured  code 

•  Entities 

(Some/all  may 

•  Logic  tracing 

•  Relationships 

be  involved) 

•  Created  modules 

•  Data  base  structures 

•  Graphical  manipulation 

•  Objects 

2.  Exclusions  from  this  Report 

This  report  covers  business-related  CASE.  It  does  not  include  CASE 
tools/methodologies  that  focus  on: 

•  Microprocessor  design 

•  Real-time  systems 

•  Embedded  systems 

•  Scientific/engineering  applications 
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In  addition,  this  report  does  not  include: 

•  Traditional  compilers  and  debuggers 

•  Fourth-generation  languages  (4GL) 

•  Data  base  access  languages  (e.g.,  SQL  and  related  tools) 

•  Data  base  tools 

•  Project  management  systems 

These  areas  are  analyzed  in  INPUT'S  report,  U.S.  Systems  Software 
Products,  1990-1995. 


Methodology 


E 


The  following  sources  were  used  for  this  report: 

•  A  written  questionnaire,  completed  by  92  CIOs  (Appendix  A) 

•  Telephone  interviews  with  14  senior  IS  executives  (Appendix  B) 

•  Telephone  interviews  with  20  application  development  managers 
(Appendix  C) 

•  Telephone  interviews  with  13  leading  CASE  vendors  (Appendix  D) 

In  addition,  INPUT  staff  held  in-depth  meetings  with  senior  staff  of  over 
20  CASE  vendors  and  other  information  services  vendors,  to  gain 
insights  into  the  direction  of  CASE  and  related  services. 


Report  Structure 


The  remaining  chapters  of  this  report  are  organized  as  follows: 

•  Chapter  11,  Executive  overview,  provides  a  summary  of  the  contents  of 
the  report 

•  Chapter  III,  User  Requirements,  reports  on  INPUT'S  research  and 
analysis  in  the  following  areas: 

-  CASE  in  the  overall  IS  context 

-  CASE  problems  and  issues 

-  CASE  planning 

•  Chapter  FV,  the  Impact  of  Technical  Issues,  examines  three  key  issues 
affecting  CASE  progress:  integration,  re-engineering,  and  distributed 
applications  development. 

•  Chapter  V,  Market  Forecasts,  provides  scenarios  affecting  CASE 
growth  and  quantifies  the  size  of  the  CASE  product  market  from 
1991-1996  under  different  sets  of  assumptions. 
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•  Chapter  VI,  Competitive  Environment,  analyzes  the  following  issues: 

-  AD/Cycle 

-  Leading  CASE  product  vendors 

-  CASE  strategies  of  selected  vendors 

-  The  impact  of  CASE  on  professional  services/sy stems  integration 
firms 

•  Chapter  VII,  Conclusions  and  Recommendations,  summarizes 
INPUT'S  findings  and  proposes  short-  and  longer-term  actions  for  both 
users  and  vendors. 

•  Appendixes  include: 

-  Appendix  A  -  IS  Management  Questionnaire  (mail  questionnaire) 

-  Appendix  B  -  IS  Management  Questionnaire  (telephone  question- 
naire) 

-  Appendix  C  -  Application  Development  Manager  Questionnaire 

-  Appendix  D  -  CASE  Vendor  Questionnaire 


Related  Reports  Please  refer  to  the  following  related  INPUT  reports: 

Managing  Information  Technology  in  the  1990s 
Developments  in  End-User  Computing 
Data  Base  Systems  Development 
US.  Systems  Software  Products,  1990-1995 
U.S.  Professional  Services  Market,  1990-1995 
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Executive  Overview 


CASE  (computer-aided  systems  engineering)  has  held  out  the  promise 
since  the  mid-1980s  of  making  a  significant  impact  on  the  applications 
development  process.  CASE  proponents  see  opportunities  for  significant 
improvements  in 

•  The  elapsed  time  it  takes  to  develop  applications 

•  Application  quality 

•  IS  staff  productivity 

CASE  could  potentially  have  an  even  broader  impact  on  the  information 
services  industry  and  corporations  in  general. 

This  promise  has  so  far  been  largely  delayed,  for  reasons  described  in  this 
report.  INPUT'S  research  has  identified  several  critical  variables  that 
have  affected  CASE  progress.  This  report  analyzes  and  quantifies  these 
variables  and  forecasts  CASE  growth  under  several  conditions. 


CASE  Stages  Based  on  INPUT'S  research  and  analysis,  INPUT  has  divided  CASE  into 

four  stages  of  development  (Exhibit  II- 1). 

•  The  first  two  stages  focused  on  individual  tools  and  how  they  could  be 
used  together. 

•  The  third  stage,  repository-based  tools,  became  the  dominant  mode  in 
1990  with  the  announcement  of  AD/Cycle.  (Texas  Instruments  and 
KnowledgeWare  each  had  earlier  repository-based  products.) 

The  third  stage  represents  a  definite  break  with  the  past.  The  transition 
from  Stage  3  to  Stage  4  will  be  more  gradual. 
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A  CASE  repository-based  environment  (Exhibit  II-2)  will  provide: 

•  A  suite  of  tools 

•  A  common  repository  for  information  exchange  and  tool  coordination 

•  Forward  engineering  facilities  (Stage  3) 

•  Re-engineering  facilities  (Stage  4) 
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EXHIBIT  11-2 
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The  most  likely  growth  scenario  for  CASE  products  in  the  1990s  is 
indicated  in  Exhibit  II-3. 


CASE  Product  Growth  Scenarios:  Summary 
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•  This  represents  an  increase  from  about  $450  million  in  1991  to  over 
$1.2  billion  in  1996,  a  22%  compound  average  annual  growth  rate. 

•  INPUT  expects  that  the  growth  rate  will  increase  from  15%  in  the 
1990-1991  period  to  25%  in  the  1995-1996  period. 

The  growth  shown  here  is  for  CASE  software  products,  since  this  is 
currently  the  only  part  of  the  CASE  market  it  is  feasible  to  measure. 
While  CASE  may  have  significant  effects  on  hardware  sales  and  will 
heavily  influence  the  professional  services  market,  it  is  not  possible  at 
this  time  to  isolate  the  effects  of  CASE  alone.  INPUT  believes  that  the 
growth  rates  shown  here  are  a  good  indicator  for  overall  CASE  use 
within  corporations. 

CASE  product  revenues  could  be  as  little  as  $800  million  in  1996  or  as 
much  as  $2.2  billion. 

•  INPUT  estimates  there  is  approximately  a  25%  probability  of  the  low- 
growth  scenario  occurring. 
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•  INPUT  gives  a  25%  probability  for  the  high-growth  scenario  occurring. 

Based  on  its  research,  INPUT  has  identified  two  principal  variables  that 
will  impact  CASE  growth: 

•  A  group  of  "soft"  issues  that  denote  an  organization's  readiness  to 
absorb  and  use  CASE  technology 

•  The  extent  to  which  re-engineering  technology  develops  and  is  put  to 
use 

These  issues  are  analyzed  in  the  next  two  sections. 


CASE  Readiness 


Part  of  input's  research  included  probing  for  the  issues  and  problems 
facing  corporations  in  making  CASE  work.  These  issues  were  classified 
and  then  categorized  as  being  either  technology-related  or  "soft"  issues 
(e.g.,  methodology,  knowledge,  training,  organization/culture,  etc.). 

•  Eighty  percent  of  respondents  cited  at  least  one  "soft"  issue  as  being  a 
key  problem  (Exhibit  II-4). 


EXHIBIT  11-4 


Technology  vs.  "Soft"  CASE  Problems 

Technology  Only 


No  Problems 
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Percentage  of  respondents  citing  problem  types 
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•  Forty  percent  cited  only  soft  issues  as  being  important  (as  opposed  to 
10%  who  cited  only  technology  issues). 

These  findings  indicated  that  CASE  users  are  not  looking  for  and  do  not 
expect  a  "silver  bullet"  in  the  form  of  a  plug-in  package.  Rather,  they 
appreciate  that  CASE  is  a  process,  almost  a  way  of  life.  Technology  is  a 
precondition  for,  but  not  a  guarantee  of,  success. 

A  critical  associated  finding  is  that  both  vendors  and  IS  departments 
place  high  importance  on  understanding  the  reasons  for  CASE  success 
(Exhibit  n-5).  However,  there  is  a  significant  gap  between  this  impor- 
tance and  how  much  knowledge  either  vendors  or  IS  departments  now 
have.  Filling  this  gap  should  be  a  critical  near-term  goal  for  most  organi- 
zations. 


EXHIBIT  II-5 


Understanding  Reasons  for  CASE  Success: 
Importance  and  Current  Knowledge  of  Vendors  and 

IS  Departments 


Vendors 


IS  Departments 


Low  High 


n-6 


0 1991  by  INPUT.  Reproduction  Prohibited. 


UIIS1 


THE  FUTURE  OF  CASE:  1991-1996 


INPUT 


D  

Re-engineering  Re-engineering,  as  INPUT  defines  it,  encompasses: 

•  Reverse  engineering  (i.e.,  stabilizing  an  application  for  CASE-led 
maintenance) 

•  Re-used  applications  (i.e.,  where  a  repository  is  populated  by  the  logic 
of  an  old  application  to  which  forward-engineering  technology  is  then 
applied.) 

Currently,  CASE  technology  and  methodology  is  largely  forward  engi- 
neering oriented. 

•  In  1991  this  limits  CASE  to  roughly  one-third  of  the  potential  applica- 
tions development  market.  (This  market  includes  maintenance  and 
modifications  activities.) 

•  By  1996,  INPUT  estimates  that  almost  half  the  applications  develop- 
ment market  could  make  use  of  re-engineering  technology.  Little  more 
than  10%  could  utilize  forward  engineering  technology,  as  now  de- 
fined. 

Consequendy,  the  development  of  re-engineering  technology  is  very 
important  for  CASE  take-off  in  the  1990s.  fNPUT  has  assessed  the 
technical  probability  of  re-engineering  meeting  the  needs  of  stage  4 
CASE. 

•  There  is  a  very  high  probability  that  back-end  CASE  logic  can  be  used 
to  populate  repositories  within  a  forward-engineering  environment. 

•  There  is  almost  as  good  a  chance  that  a  back-end  to  front-end  link  can 
be  established  within  reverse  engineering. 

E   " 

CASE  Impact  Currently,  the  impact  of  CASE  techniques  and  technologies  within  the 

typical  corporation  is  quite  low. 

•  input's  research  shows  a  low  level  of  perceived  effectiveness. 

•  The  great  majority  of  organizations  are  using  only  a  partial  set  of  CASE 
tools,  generally  within  only  a  part  of  the  organization. 

The  result  is  a  vicious  circle  (Exhibit  II-6).  The  set  of  "soft"  problems 
does  not  make  the  situation  any  easier  to  resolve. 

On  the  other  hand,  a  successful  CASE  take-off  may  take  people  by 
surprise,  since  the  planning  lead  time  for  developing  a  CASE  strategy  can 
be  lengthy.  As  Exhibit  11-7  shows,  many  groups  would  be  affected  if 
CASE  assumed  a  high  profile. 
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EXHIBIT  11-6 


CASE'S  Vicious  Circle  and  Its  Effects 
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•  CASE  would  affect  how  work  would  be  conducted,  which  would  have 
a  significant  impact  on  application  developers,  user  departments,  and 
professional  services/systems  integration  firms.  (Besides,  of  course, 
CASE  product  vendors  themselves.) 

•  The  roles  of  application  developers,  application  software  vendors,  and 
professional  services/systems  integration  firms  would  change  signifi- 
cantly. 

•  Business  strategies  would  (or  certainly  should)  undergo  very  signifi- 
cant changes  as  both  IS  and  non-IS  groups  worked  out  the  implications 
of  successful  CASE  (that  is  "faster-better-cheaper"). 
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EXHIBIT  11-7 


Impact  of  CASE  Take-Off 
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F  

AD/Cycle  AD/Cycle  has  revolutionized  the  CASE  environment  since  it  was  an- 

nounced in  September  1989. 

•  It  meets  the  market's  expectations  for  an  integrated,  repository-based 
product. 

•  The  equity  investment  strategy  means  that  IBM  can  credibly  offer  other 
vendors'  products  as  an  integral  part  of  AD/Cycle. 

•  Both  customers  and  other  vendors  have  generally  welcomed  the  con- 
cept of  a  de  facto  CASE  standard  on  the  IBM  platform. 

The  market  acceptance  of  AD/Cycle  is  shown  in  Exhibit  II- 8,  where  AD/ 
Cycle  (not  KnowledgeWare,  etc.)  is  generally  the  planned  CASE  product 
of  choice. 

IBM's  strategy  is  to  use  CASE  to  sell  more,  possibly  much  more,  IBM 
hardware  by  greatly  improving  applications  quality,  timeliness,  and 
development  costs  (Exhibit  11-9).  For  IBM  this  is  too  important  to  leave 
to  third-party  CASE  product  vendors:  Andersen  and  Texas  Instruments 
have  recentlyTconcluded  agreemenf^with  DEC  to  move  their  tools  from 
the  IBM  platform  to  the  DEC  platform.  This  shows  that  there  are  few 
significant  impediments  to  redirecting  a  CASE  tools  output  from  one 
hardware/software  platform  to  another. 
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AD/Cycle's  Market  Share 
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EXHIBIT  11-9 


IBM's  Intermediate  and  Final  CASE  Objectives 
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By  controlling  AD/Cycle,  IBM  will  offer  rapid  development  in  a  context 
that  will  ensure  IBM's  general  control  of  the  process  through: 

•  Maintaining  a  de  facto  standard 

•  Offering  CASE  product  options  within  AD/Cycle  (e.g., 
KnowledgeWare  versus  Index  versus  IBM) 

•  Co-opting  many  potential  third-party  competitors 

•  Encouraging  AD/Cycle-based  application  software  products 
Nothing  like  AD/Cycle  is  yet  on  the  horizon  in  the  non-IBM  world 


Other  Vendors 


CASE  product  vendors  and  professional  services/systems  integration 
firms  have  important  near-term  decisions  to  make. 


CASE  product  vendors  have  several  options  in  dealing  with  AD/Cycle,  as 
shown  in  Exhibit  11-10. 
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AD/Cycle  CASE  Vendor  Options 
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•  They  can  build  a  firewall  between  themselves  and  AD/Cycle  by  offer- 
ing: 

-  Totally  separate  products  on  non-IBM  platforms  with  few  connec- 
tions to  AD/Cycle.  Today,  fewer  vendors  are  taking  this  route 
compared  to  a  year  ago. 

-  An  alternate  approach  is  to  develop  products  for  (or  ports  to)  non- 
IBM  platforms,  as  Andersen  and  Texas  Instruments  are  now  doing 
with  DEC. 

•  More  common  is  the  "bridge"  approach,  where  a  vendor  promises  to 
remain  compatible  with  AD/Cycle.  The  long-term  feasibility  of  this 
approach  is  difficult  to  evaluate  now,  given  the  unfinished  aspects  of 
AD/Cycle. 

•  The  niche  alternative  within  AD/Cycle  is  one  that  is  only  beginning  to 
emerge.  The  best  example  of  this  is  the  Bachman  Information  Systems 
data  base  design  and  migration  tools. 

Professional  services/systems  integration  firms  have  the  most  options  to 
choose  from  now  (see  Exhibit  II- 1 1).  These  are  very  important  choices 
since  a  large  portion  of  the  business  of  these  firms  is  apphcation  develop- 
ment. 
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EXHIBIT  11-11 


Professional  Services/Systems  Integration  Firms 

CASE  Alternatives 


Strategic  Choices 


•  Retaining  conventional  application  development  approaches  is  the 
easiest,  but  would  leave  such  firms  far  behind  if  and  when  CASE  does 
become  critical. 

•  A  CASE-driven  strategy  may  only  utilize  a  firm's  own  tools  or,  at  the 
other  extreme,  be  less  selective  on  the  specific  CASE  tools  utilized. 

-  Using  proprietary  tools  can  lead  to  the  development  of  internal  skills 
and  therefore  help  maintain  account  control;  this  assumes  that  propri- 
etary tools  are  competitive  in  the  long  and  short  run. 

-  An  "open"  CASE  approach  can  mean  selecting  the  best  set  of  tools; 
however,  staff  may  not  attain  a  critical  mass  of  knowledge. 
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•  There  can  be  a  great  range  of  closeness  and  exclusivity  in  partnerships. 
The  basic  trade-off  is  influence  on  the  other  party  versus  dependency 
on  an  outside  organization. 

Of  any  group  involved  with  CASE,  professional  services  firms  and 
systems  integrators  have  the  most  complex  and  important  decisions  to 
make. 
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User  Requirements 


This  chapter  examines  user  requirements  and  plans.  Issues  analyzed 
include: 

•  The  effectiveness  of  CASE  within  the  broader  IS  context 

•  The  current  status  of  CASE,  i.e.,  the  extent  to  which  it  is  now  used 

•  CASE  problems  and  related  issues 

•  Planning  for  CASE 

A  

CASE  in  the  IS  At  the  end  of  1990,  INPUT  asked  IS  executives  to  rate  the  relative  impor- 

Context  tance  of  the  following  technical  and  non-technical  applications  develop- 

ment-related issues: 

•  End-user  development 

•  Vendor  assistance 

•  IS  funding 

•  IS  personnel  availability 

•  Workstation-based  development 

•  Maintenance  and  re-engineering 

•  Distributed  DBMS 

•  Relational  DBMS 

•  CASE 

The  most  important  issues  by  far  were  those  involving  resource  con- 
straints, as  shown  in  Exhibit  III-l.  They  are: 

•  Funding 

•  Maintenance 

•  Personnel  availability 


UIIS1 


©  1991  by  INPUT.  Reproduction  Prohibited. 


ni-1 


THE  FUTURE  OF  CASE:  1991-1996 


INPUT 


EXHIBIT  III-1 


IS  Management  Ratings  of  Most  Important  Issues 
Connected  with  Systems  Development 
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Given  the  realities  of  most  IS  departments,  these  findings  should  not  be  a 
surprise.  What  may  be  a  surprise  at  first  is  that  only  2%  of  the  IS  execu- 
tives interviewed  considered  CASE  their  most  important  issue 
(Exhibit  III-2);  however,  a  majority  did  include  CASE  among  their  top 
five  issues.  On  closer  examination,  not  having  jumped  aboard  the  CASE 
bandwagon  has  up  to  this  point  made  sound  business  sense: 

•  CASE  is,  in  most  respects,  just  out  of  its  infancy.  (See  Chapter  IV.) 

•  While  AD/Cycle  may  have  put  a  powerful  "blessing"  on  CASE,  many 
IS  organizations  spent  1990  reflecting  on  just  what  this  meant. 

•  Most  importandy,  the  real  users  of  CASE,  the  systems  development 
departments,  have  yet  to  see  significant  results  themselves.  Exhibit  III- 
3  shows  a  rating  of  CASE  effectiveness  by  IS  executives.  The  average 
rating  of  2.6  on  a  scale  of  5  is  not  at  all  impressive;  over  50%  rated 
CASE  progress  as  less  than  satisfactory. 

This  analysis  is  not  intended  to  present  a  gloomy  picture  of  CASE'S 
future  or  technical  attractiveness.  Rather,  it  emphasizes  the  fact  that 
CASE  users,  especially  CASE  decision  makers,  have  to  balance  CASE 
issues  among  many  other  issues. 
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Importance  of  CASE  to  IS  Management 
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CASE  Status 


As  noted  in  the  prior  section,  most  IS  executives  rate  CASE  effectiveness 
relatively  low  (Exhibit  III-3).  These  low  ratings  of  effectiveness  are  not 
a  result  of  IS  executives  being  unfamiliar  with  CASE: 


Three-quarters  of  large  corporations  interviewed  by  INPUT  are  using 
CASE  at  least  partially  (Exhibit  ni-4).  Partial  use  can  mean  either 
using  only  some  CASE  functions  for  limited  projects,  or  using  limited 
CASE  tools  on  a  few  projects. 


EXHIBIT  III-4 


1991  CASE  Use 


•  There  is  still  a  great  deal  of  anecdotal  evidence  concerning  CASE 
"shelfware",  i.e.,  CASE  tools  bought  but  used  to  a  very  limited  extent. 
One  large  bank,  for  example,  is  said  to  have  over  100  packages  of 
CASE  workstation  software  sitting  unopened. 

A  majority  of  corporations  interviewed  are  using  a  CASE  tool  (Exhibit 
in-5)  for  at  least  one  of  the  three  major  functions  of  forward  engineer- 
ing— ^requirement  analysis,  system  design,  or  code  generation. 

However,  most  users  are  still  using  CASE  tools  in  an  unintegrated 
manner  (Exhibit  ni-6).  Consequentiy,  the  situation  is  one  where  some 
kind  of  CASE  tool  has  been  acquired  by  most  organizations.  However, 
full  use  and  penetration  is  still  quite  modest. 

Given  this  environment,  it  is  quite  logical  that  IS  executives  do  not  yet 
give  CASE  their  full  attention  (Exhibit  111-2)  nor  see  signs  of  CASE 
effectiveness  (Exhibit  111-3). 
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EXHIBIT  III-5 


1991  CASE  Use,  by  Function 
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EXHIBIT  III-6 


Degree  of  CASE  Tool  Integration 
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CASE  Problems  and      The  preceding  sections  of  this  chapter,  noted  the  relationship  between 
Issues  partial  CASE  use,  lack  of  demonstrated  CASE  effectiveness,  and  the 

placement  of  secondary  emphasis  by  IS  management  on  CASE  issues. 

•  This  is  often  circular,  when  IS  management  attaches  less  importance  to 
CASE,  this  can  influence  only  partial  CASE  use,  which  in  tum  can 
create  a  vicious  circle  of  low  use  and  low  expectations. 

•  Partial  CASE  use  and  limited  CASE  effectiveness  are  causes  as  well  as 
effects  of  perceived  CASE  problems  among  CASE  users. 

Exhibit  ni-7  illustrates  these  relationships. 


EXHIBIT  III-7 


CASE'S  Vicious  Circle  and  Its  Effects 


Secondary 
Management 
Emphasis 


Lack  of 
Demonstrated 

CASE 
Effectiveness 


Partial 
CASE  Use 


\  / 

\  / 

Open  Issues/ 
Problems 


As  part  of  INPUT'S  research,  INPUT  asked  those  knowledgeable  in  their 
company's  CASE  operations  to  discuss  their  problems  and  other  open 
issues  they  see  relating  to  CASE.  The  responses  were  then  classified 
into  the  following  categories: 
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•  Integration  of  tools,  processes,  and  methodologies 

•  The  acceptance  of  CASE  by  the  existing  organizational  structure  and 
culture 

•  Establishing  or  choosing  an  appropriate  methodology  for  the  organiza- 
tion, while  at  the  same  time  receiving  the  benefits  of  common  standards 

•  Identifying  appropriate  levels  of  CASE  knowledge  for  the  organization 
and  providing  effective  training  ' 

•  Establishing  the  true  costs  and  benefits  of  CASE 

•  Maintenance  and  re-engineering 

•  Deciding  the  appropriate  relationship  between  using  CASE  to  build 
applications  and  using  software  packages. 

The  percentage  of  respondents  that  cited  each  issue/problem  group  is 
shown  in  Exhibit  111-8.  The  interesting  thing  about  these  issues/problems 
is  how  they  can  be  divided  into  technology  issues  (integration,  re-engi- 
neering and,  to  a  large  degree,  packages  versus  CASE)  and  the  "soft" 
issues  (organization/culture,  knowledge/training,  methodology/standards, 
and  cost/benefit). 

•  Only  10%  of  respondents  saw  their  problems  as  involving  only  technol- 
ogy issues.  (Exhibit  ni-9) 

•  In  contrast,  40%  cited  no  technology  issues  but  only  "soft"  issues. 
(Only  10%  cited  no  problems  at  all) 

•  While  half  cited  at  least  one  technology  issue,  80%  cited  at  least  one 
"soft"  issue. 

A  very  important  conclusion  from  this  is  that  CASE  is  not  perceived  as 
being  primarily  a  technology  question.  In  general  it  is  more  important  to 
deal  with  the  context  in  which  CASE  will  succeed  (or  fail). 

•  The  "soft"  issues  revolve  around  the  organization/culture  question 
(Exhibit  III- 10).  Methodology  and  training  must  relate  to  the  specific 
corporate  context  if  CASE  is  going  to  succeed.  Cost/benefit  and  other 
issues  are  also  tied  to  the  organization/culture  question,  although  not 
always  as  tightly. 
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EXHIBIT  III-8 


CASE  Problems  and  Unresolved  Issues 
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Note:  Total  of  percents  is  more  than  100%  due 
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EXHIBIT  III-9 


Technology  vs.  "Soft"  CASE  Problems 

Technology  Only 

/\  10% 

Cited  /  \ 
/  10%  \ 

Technology  \ 
and  "Soft"  \ 

.  40% 

\       "Soft"  Only 

\  40% 

Percentage  of  respondents  citing  problem  types 

•  Similarly,  integration  is  the  key  issue  in  technology  (Exhibit  III-l  1).  It 
was  perceptive  that  so  many  respondents  identified  the  general  issue 
(integration)  rather  than  one  of  its  near-term  manifestations  (reposito- 
ries) as  being  the  issue. 

One  of  the  critical  issues  for  corporations  is  to  understand  the  precise 
reasons  for  CASE  success  and  failure. 

•  IS  departments  state  that  understanding  the  concrete  reasons  for  CASE 
success  and  failure  is  very  important  to  them  (Exhibits  111-12  and  III- 
13).  However,  IS  departments  are  not  nearly  as  satisfied  that  they  are 
receiving  the  kind  of  information  that  will  allow  them  to  understand  the 
constituents  of  success  and  how  to  apply  them. 
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'Soft"  Issues — Relationships 


Methodology/ 
Standards  (30%) 
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 ►  Tight  Linkage 

—      Loose  Linkage 
Note:  Percents  refer  to  proportion  of  respondents  citing  issue 
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Technology  Issues — Relationships 

Integration 
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Applications 
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Understanding  Reasons  for  CASE  Success: 
Importance  and  Current  Knowledge  of  Vendors  and 

IS  Departments 


Vendors 


-  This  gap  is  even  wider  regarding  the  need  to  understand  the  causes  of 
CASE  failure. 

-  CASE  users  and  prospects  are  cautious  concerning  vendor-sponsored 
illustrations  of  CASE  success.  However,  such  illustrations  are  better 
than  no  information  at  all. 

-  Analyses  of  CASE  failure  (absolute  or  relative)  are  much  harder  to 
come  by  than  stories  of  success;  no  vendors  and  few  corporations 
have  any  incentive  to  disclose  their  problems,  even  if  others  will 
benefit  from  their  mistakes. 

•  The  importance  and  knowledge  ratings  supplied  by  vendors  closely 
mirror  those  of  IS  departments,  showing  among  other  things,  that: 

-  Vendors  also  recognize  that  there  is  a  problem  that  is  not  being 
addressed. 

-  Vendors  have  no  secret  store  of  knowledge  being  withheld  for  com- 
petitive reasons. 
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Information  on  CASE  Failures:  Importance  and 
Current  Knowledge  of  Vendors  and  IS  Departments 
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The  more  abstract  "critical  CASE  success  factors"  (Exhibit  111-14)  track 
fairly  closely  to  the  need  for  success/failure  analysis. 


Information  on  Critical  CASE  Success  Factors: 
Importance  and  Current  Knowledge  of  Vendors  and 

IS  Departments 


Vendors 
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•  The  gap  among  IS  departments  between  importance  and  knowledge  is 
a  little  less  pronounced. 

•  However,  vendors  profess  to  be  more  satisfied  with  the  information 
they  have  available.  Vendors  may  in  fact  know  more  than  the  typical 
CASE  client;  however,  it  is  likely  that  vendors  know  general  success 
factors  and  not  necessarily  those  applicable  to  a  specific  user  organiza- 
tion. 


CASE  Planning  IS  departments  are  at  a  crossroads  in  their  CASE  efforts.  Even  though 

CASE  activities  have  not  produced  many  results  so  far,  IS  departments 
are  quite  aware  of  the  potentially  favorable  impact  of  CASE  on  produc- 
tivity, system  quality,  applications  design,  and  end-user  involvement. 
This  section  will  report  on  some  of  these  expectations  as  well  as  high- 
light the  gaps  in  knowledge  that  impede  progress. 

Both  vendors  and  IS  departments  see  CASE  technology  as  having  a 
fairly  significant  impact  on  the  applications  design  process  generally, 
although  both  are  not  too  satisfied  that  they  understand  the  exact  form 
this  will  take  (Exhibit  III- 15). 


Impact  of  CASE  Technology  on  Applications  Design: 
Importance  and  Current  Knowledge  of 
Vendors  and  IS  Departments 
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•  In  large  part  this  is  because  the  relationship  of  applications  design 
methodology  to  the  underlying  CASE  technology  is  still  not  clear. 
CASE  vendors  profess  to  be  "methodology-neutral." 

•  This  causes  many  IS  organizations  to,  at  best,  re-invent  the  wheel.  In 
reality  most  of  the  wheels  invented  are  of  different  shapes  and  sizes. 

IS  departments  see  the  potential  impact  on  end  users  as  being  even  more 
important  than  the  impact  on  the  applications  design  process  (Exhibit  III- 
16).  However,  the  gap  between  the  perceived  importance  and  their 
understanding  of  how  this  will  come  about  is  very  wide. 

•  Anyone  who  has  seen  a  business  analyst  and  a  systems  analyst  sit  side- 
by-side  at  a  workstation  while  working  through  applications  logic  can 
understand  the  enormous  promise. 

•  However,  making  this  a  day-to-day  reality  is  difficult.  Even  more 
difficult  is  the  task  of  incorporating  organizational,  methodological,  and 
training  changes  needed  to  provide  successful  CASE  implementations 
consistently. 

•  There  are  practically  no  "how-to's"  in  even  a  crude  form  to  assist 
corporations  in  making  extensive  end-user  involvement  a  reality. 

Vendors  place  considerably  less  importance  on  end-user  involvement 
than  IS  departments  (Exhibit  111-16).  In  INPUT'S  view  this  reflects  the 
technology/tool  focus  of  most  vendors  and  the  inability  of  today's  prod- 
ucts to  treat  the  business  analyst  user  as  part  of  the  design  process. 


EXHIBIT  111-16 


CASE  Impact  on  End-User  Departments: 
Importance  and  Current  Understanding  of  Vendors 
and  IS  Departments 
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Interim  Conclusions      It  is  fair  to  say  that  much  of  CASE  planning  has  been  provisional  up  to 

now,  as  firms  attempt  to: 

•  Understand  the  technology 

•  Fit  CASE  technology  into  their  own  systems  objectives 

•  Adjust  CASE-related  objectives  to  the  broader  coiporate  environment 
and  goals. 

Part  of  the  difficulty  in  adjusting  to  CASE  may  be  a  result  of  the  decen- 
tralization of  many  IS  functions  in  the  last  decade.  Organizational 
decentralization  and  CASE  integration  may  be  at  least  partially  in  con- 
fiict.  This  subject  needs  more  study. 

According  to  INPUT'S  research,  only  one- third  of  firms  feel  comfortable 
with  the  CASE-related  plans  they  have  already  made  (Exhibit  III- 17). 


EXHIBIT  111-17 


Corporate  Expectation  of  Making 
Changes  to  CASE  Plans 


Other  Technical 
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•  One-quarter  are  not  sure  of  their  position. 

•  Forty  percent  expect  to  make  changes;  half  of  this  group  (20%  of  all 
respondents)  have  already  decided  to  adopt  AD/Cycle. 

This  last  finding  certainly  indicates  the  power  of  IBM's  marketing  ef- 
forts, but  it  shows  considerably  more: 

•  AD/Cycle  embodies  the  integration  important  to  so  many  IS  organiza- 
tions. 

•  The  repository  concept  is  very  powerful  and  finds  immediate  appeal. 

•  AD/Cycle  shows  IBM's  enormous  commitment  to  CASE  concepts; 
there  is  no  question  of  AD/Cycle 's  staying  power. 

The  CASE  community  had  for  some  time  before  the  AD/Cycle  an- 
nouncement been  looking  for  some  entity  to  bring  order  to  the  overall 
CASE  environment.  As  the  impact  of  AD/Cycle  began  to  become  clear 
in  the  course  of  1990,  INPUT  had  dialogs  with  major  vendors  about  their 
response  to  AD/Cycle;  the  reacdons  were  virtually  identical: 

•  This  was  the  announcement  that  the  CASE  community  had  been  wait- 
ing for  to  bring  order  to  the  CASE  marketplace. 

•  Even  firms  most  damaged  by  AD/Cycle  stated  that  the  introduction  of 
AD/Cycle  was  an  absolutely  necessary  and  desirable  event. 

The  next  chapter,  which  analyzes  CASE  technical  issues,  provides  more 
background  on  why  AD/Cycle  has  been  received  so  positively. 
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The  Impact  of  Technical  Issues 


Systems  engineering,  and  its  manifestation  as  CASE,  can  sometimes 
appear  to  be  an  end  in  itself.  Academics  and  researchers  (as  well  as  self- 
interested  vendors)  discuss  at  length  their  positions  on  such  issues  as 
methodologies,  data  and  process  representation,  the  place  for  object- 
oriented  design,  information  modeling  alternatives,  etc.  These  are  all 
important  issues.  However,  the  ultimate  justification  for  CASE  is  how 
useful  it  is  to  application  developers. 

INPUT  has  found  that  three  straightforward  questions  serve  as  a  good  test 
forjudging  CASE  technical  issues  against  the  demands  of  the  real  world; 
these  questions  are  shown  in  Exhibit  IV- 1. 


CASE  Technology  Assessment  Criteria 


•  Will  the  particular  technology  solve  important,  real 
problems? 

•  How  adaptable  is  the  technology  to  current 
environments?  Are  there  many  overhead  or 
migration  resources  required  to  take  advantage  of 
the  technology? 

•  How  much  investment — in  people,  dollars  and 
time — is  required  before  significant  benefits  can  be 
expected? 
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This  chapter  will  examine  three  issues  that  relate  to  CASE  technical 
issues: 

•  Integration 

•  Re-engineering 

•  Distributed  applications  development 

Each  of  these  technical  issues  will  be  judged,  implicitly  and  explicidy  in 
terms  of  the  three  questions  in  Exhibit  IV- 1 . 


Stages  of  Integration 


Integration  has  been  a  key  CASE  issue  from  the  beginning.  Dealing  with 
integration — or,  more  usually,  inadequacy  in  dealing  with  it — has  been 
an  important  determinant  of  CASE  progress  and  acceptance. 

input's  analysis  categorizes  CASE  into  four  stages,  as  shown  in 
Exhibit  IV-2: 


EXHIBIT  IV-2 
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•  Each  Stage  has  a  beginning  and,  at  least  for  the  first  two  stages,  an  end. 

•  Each  stage  has  a  period  during  which  it  is  dominant,  as  well  as  second- 
ary period(s),  that  represent  that  stage's  ascent  or  decline. 

Stage  1:  Standalone  CASE  Tools 

This  is  by  now  CASE*s  pre-history,  but  it  is  still  important  for  an  under- 
standing of  overall  CASE  trends.  Both  front-end  and  back-end  CASE 
tools  were  important  in  Stage  1  (see  Chapter  1  for  definitions  of  CASE 
tools).  However,  front-end  tools  became  especially  prominent  due  to  the 
following  interrelated  developments. 

•  Graphics-oriented  workstations  for  representing  data  and  process 
relationships  became  increasingly  capable  and  inexpensive;  originally, 
specialized  graphics  workstations  were  used,  but  soon  standard  PCs 
were  acceptable. 

•  Information  modeling  methodologies  became  increasingly  sophisticated 
as  well  as  more  practical. 

•  While  it  cannot  be  proved  conclusively,  it  seems  apparent  in  retrospect 
that  the  technological  and  conceptual  developments  were  mutually 
reinforcing. 

Stage  1  front-end  technology  could  soon  produce  analysis  and  designs 
that  were: 

•  Graphical 

•  Self-documenting 

•  Most  importantly,  sharable  with  non-technicians  (e.g.,  business  ana- 
lysts) 

Back-end  technology  during  Stage  1  did  not  represent  the  potential 
breakthrough  that  Stage  1  front-end  technology  did.  Back-end  technol- 
ogy represented  iterative  improvements  to  traditional  coding,  but  was 
still: 

•  Character  based 

•  Procedural  (in  concept) 

•  Code  oriented 

•  Inaccessible  to  non- technicians 
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•  Most  importantly,  the  output  of  traditional  code  could  be  (and  often 
was)  independently  maintained. 

If  the  generated  code  could  be  maintained  independently,  then  there 
could  not  be  ironclad  assurance  that  the  application-as-documented  (i.e., 
the  generator  input)  would  be  the  same  as  the  application-as-modified 
(i.e.,  the  working  code).  This  represents  the  continuation  of  the  age-old 
"patch"  problem,  where  important  changes  are  not  kept  track  of  coher- 
ently. Library  control  is  a  fall-back  position  but  is  primarily  an  audit 
function  rather  than  an  assistance  in  development. 

The  largest  problem  with  Stage  1  tools  is  that  each  was  isolated  from  the 
other,  as  shown  in  Exhibit  IV- 3: 


Stage  1  (Mid-1980s) 
Standalone  CASE  Tools 
(Schematic) 

A  ® 
A  ® 
A  ® 

A 

Note:    Letters  within  symbols  refer  to  individual  vendors 
^     ^  Methodologies 


Analysis/design  tools 
Generators 
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•  It  was  Up  to  the  customer,  with  varying  degrees  of  assistance  from 
vendors,  to  tie  tools  together.  Even  if  it  were  feasible  for  a  customer  to 
do  so  (and  for  all  but  the  largest  IS  organizations  it  would  not  be),  this 
would  rarely  be  a  worthwhile  use  of  resources. 

•  Consequentiy,  during  this  period,  CASE  tools  were  almost  always 
merely  adjuncts  to  business  as  usual — ^perhaps  producing  pretty-looking 
documentation,  but  documentation  just  as  likely  to  become  instantly 
obsolete  as  traditional  documentation. 

•  Stage  1  was  the  Golden  Age  of  CASE  shelf  ware,  as  customers  found 
that  making  CASE  useful  was  far  more  difficult  than  they  had  led 
themselves  to  believe. 

Stage  2:  Linked  Tools 

As  Stage  1  developed,  the  defects  inherent  in  having  islands  of  CASE 
automation  became  clear  to  theorists,  vendors,  and  customers  (or  poten- 
tial customers).  The  most  straightforward  solution  was  to  have  the  tool 
vendors  take  over  the  responsibility  for  developing  links  between  tools 
for  exchanging  information  needed  for  application  development.  In  the 
mid/late  1980s  there  was  a  burst  of  announcements  from  tool  vendors 
that  they  would  support  interfaces  between  one  another.  This  was  very 
desirable  in  that  it  enabled  customers  to  focus  on  applications  develop- 
ment rather  than  development  of  CASE  linkages. 

However,  after  a  short  time  it  became  clear  that  announcing,  or  even 
initially  developing  an  interface,  was  not  a  complete  answer: 

•  There  were  no  vendor-neutral  information  interchange  standards. 

•  Information  often  had  to  be  simplified  (and  value  lost)  in  being  trans- 
lated from  one  dissimilar  architecture  to  another. 

These  technical  issues  were  serious  and  would  make  progress  difficult  at 
best.  However,  business-related  factors  were  even  larger  stumbling 
blocks: 

•  The  biggest  problem  was  the  sheer  number  of  CASE  tool  vendors.  At 
one  point  INiPUT  counted  over  140  vendors  offering  at  least  twice  that 
number  of  products.  Exhibit  rV-4  is  a  greatly  simplified  schematic  of 
the  virtually  impossible  challenges  facing  vendors  attempting  to  form 
linkages  with  each  other: 

-  How  does  one  keep  up  with  new  versions? 

-  How  should  a  partner  be  picked — on  technical  merit  or  market 
strength? 
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Stage  2  (Late  1980s) 
Linked  CASE  Tools  (Schematic) 


«  «    /  •     *    '  • 

,   *  t  A       '  * 


■    ■    ■    e  IS 


Ad  hoc,  vendor-supplied  linkage 

Intravendor  linkage 
(e.g.,  acquisition) 


Note:    Letters  within  symbols  refer  to  individual  vendors 
Project  management  systems 
^     ^  Methodologies 
yAy^  Analysis/design  tools 

Generators 


-  What  if  a  potential  partner  is  unwilling  to  cooperate? 

•  Some  vendors  formed  semiformal  relationships,  but  most  were  promis- 
cuous. Some  marriages  (i.e.,  mergers)  occurred,  but  the  total  number 
of  CASE  tool  vendors  did  not  decline  significantly. 
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Stage  2  brought  no  more  order  into  the  marketplace,  and  possibly  less, 
than  Stage  1.  Customers  (or  more  accurately,  potential  customers)  were 
as  confused  and  cautious  as  before: 

•  Some  vendors  were  beginning  to  emerge  as  leaders,  through  some 
combination  of  name  recognition,  size,  technical  attractiveness,  or 
market  power. 

•  However,  it  was  a  rash  (or  very  self-confident)  IS  department  that 
would  stake  very  much  on  a  particular  vendor  (or  combination  of 
vendors)  emerging  victorious.  To  place  a  losing  bet  might  well  have 
meant  wasted  CASE  development  time  and  resources. 

The  risks  in  Stage  2  were  often  portrayed  as  opportunities;  linkage,  for 
example,  was  described  as  a  chance  for  customers  to  select  the  "best  of 
the  breed"  of  different  CASE  tools.  In  a  more  mature  market  this  might 
have  been  possible;  as  it  was.  Stage  2  was  virtually  doomed  to  failure 
from  the  start  because  of  the  enormous  number  of  CASE  products  to 
choose  from. 

Stage  3:  Repository-Based  CASE  Tools 

Stage  3  also  grew  out  of  the  frustrations  with  the  isolated  CASE  tools  of 
Stage  1.  To  oversimplify,  linkage,  rather  than  being  secondary  (as  in 
Stage  2),  was  viewed  as  central  to  making  the  CASE  concept  function. 

•  Vendors  stopped  looking  for  a  means  of  transferring  information  on 
data  elements,  data  relationships,  and  logical  processes  between  appli- 
cation development  functions  (i.e.,  CASE  tools). 

•  Instead,  information  interchange  became  the  center  of  the  CASE  activi- 
ties. This  ehminated  the  complexities,  redundancies,  and  synchroniza- 
tion problems  inherent  in  multiple  linkages. 

•  The  contrasts  between  the  two  approaches  are  shown  in  Exhibit  IV-5. 
("Repository"  is  used  in  Exhibit  IV-5  because  that  term  has  the  most 
currency.)  The  repository  concept  has  a  simplicity  and  economy  that 
would  have  ultimately  made  Stage  2  obsolete  even  if 

-  There  had  been  an  order  of  magnitude  fewer  CASE  vendors  compet- 
ing in  Stage  2 

-  IBM  had  not  emphatically  endorsed  the  repository  concept  (and  made 
the  investments  to  make  it  real) 

The  term  repository  is  so  closely  identified  with  IBM  and  AD/Cycle  that 
it  is  sometimes  forgotten  that  IBM 
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EXHIBIT  IV-5 


Linkage  vs.  Repository  in  Information  Exchange 


Analysis 


Design 


Code  Generation 


Project 
Management 


(Stage  2) 


Design 

(Stage  3) 


Generation 


•  Was  a  relative  late-comer  in  its  public  support  of  the  repository  ap- 
proach 

•  Bought  much  of  the  core  technology  - 
On  the  other  hand,  IBM  provided  a  vital  service  by 

•  Producing  a  de  facto  standard  for  IBM  platforms 

•  Accelerating  the  shrinkage  in  the  number  of  CASE  product  vendors. 
The  "noise"  level  caused  by  dozens  of  vendors  in  the  marketplace  has 
started  to  fall. 

•  Providing  a  stable  target  for  customer  planning 

Even  in  a  repository  environment,  there  will  be  some  products  that  have 
tighter  links  than  others  (as  shown  in  Exhibit  IV-6): 


Analysis 


Project 
Management 


IV-8 
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EXHIBIT  IV-6 


Stage  3  (Early  1990s) 
Repository-Based  CASE  Tools  (Schematic) 
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Forward-Engineered 


Repository 


Application 
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Loose  linkages 
Tight  linkage 


Note:    Letters  within  symbols  refer  to  individual  vendors 


I     I   Project  management  systems 
^     y  Methodologies 
y/\  Analysis/design  tools 

Generators 


•  Certain  products/functions  will  be  supplied  by  the  same  vendor;  these 
products  will  obviously  work  more  in  concert  and  be  kept  in  better  step 
developmentally. 

•  Some  vendors,  like  those  offering  project  management  systems,  may 
wish  to  support  concurrent  projects  across  different  types  of  repository 
and  hardware  platforms.  Their  linkages  to  any  one  repository  must 
necessarily  be  looser  than  would  be  the  case  for  a  product  directed  at  a 
single  repository. 
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•  Methodologies  are  in  a  somewhat  different  position:  current  method- 
ologies, by  definition,  predate  repositories;  consequently,  a  repository 
has  to  conform  somewhat  to  existing  methodologies.  Methodologies 
have  typically  had  no  specific  vendor  sponsor.  However,  as  time  goes 
on  particular  repositories  and  closely  associated  tools  may  become 
implicitly  more  receptive  to  certain  types  of  methodologies. 

Current  repository-based  CASE  is  at  least  implicidy  aimed  at  the  forward 
engineering  of  applications.  This  places  very  real  constraints  on  its 
applicability  to  solving  real-world  applications  problems,  which  often 
involve  a  mixture  of  new  development  and  modifications  to  existing 
applications. 

Stage  4:  Repository-Based  CASE  Environment  ' 

In  some  ways  Stage  4  is  a  further  extension  of  Stage  3,  in  the  same  way 
that  Stage  2  was  an  extension  of  Stage  1: 

•  Stage  4  will  be  largely  upwardly  compatible  with  Stage  3. 

•  Stage  4  will  represent  a  series  of  incremental  changes. 

•  Stage  4  will  not  appear  dramatically  as  a  single  announcement. 

The  "blending"  of  Stage  3  into  Stage  4  will  be  represented  by  one  or 
more  vendors  developing  tightly  coupled  groups  of  tools  and  methodolo- 
gies around  a  particular  repository  architecture  (shown  in  Exhibit  IV-7). 

•  Where  the  repository  design  and  execution  is  determined  by  a  single 
vendor  (e.g.,  IBM  in  AD/Cycle),  at  least  one  set  of  associated  tools  and 
methodologies  will  be  offered — or  at  least  tightly  controlled — by  that 
vendor.  (See  Chapter  VI  for  a  more  extended  analysis  of  IBM  and  AD/ 
Cycle.) 

•  However,  it  will  generally  be  in  the  interests  of  repository  controllers 
to  allow — and  often  encourage — third  parties  to  provide  alternative  and 
niche  offerings.  This  will  provide  limited-risk  choices  as  well  as  a 
pseudo-open  architecture  for  customers  and  other  vendors. 

The  most  visible  addition  in  Stage  4  will  be  the  linkage  of  forward 
engineering  and  re-engineering  (Exhibit  IV-7).  Currently,  re-engineering 
is  isolated  from  the  rest  of  CASE  activities;  as  forward  engineering  and 
re-engineering  are  better  coordinated.  Stage  4  will  take  off  (see  Section 
C,  below). 


IV-10 


©  1991  by  INPUT.  Reproduction  Prohibited. 


UIIS1 


THE  FUTURE  OF  CASE:  1991-1996 


INPUT 


EXHIBIT  IV-7 


Stage  4  (Mid-1  ggOs) 
Repository-Based  CASE  Environments  (Schematic) 


—  Tight  linkage 

•    Intravendor  linkage 

Note: 

Letters  within  symbols  refer  to  individual  vendors 
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Integration:  Summary  Lxx)king  at  the  stages  of  CASE  development — both  past  and  future — the 

driving  force  has  been  continuing  mtegration.  This  is  squarely  in  keeping 
with.  IS  department  requirements,  as  described  in  the  prior  chapter. 
Unfortunately,  to  date  the  pace  of  integration  has  been  slow  relative  to 
user  needs.  The  announcement  and  partial  reality  of  AD/Cycle  promises 
to  bring  CASE  practice  somewhat  closer  to  CASE  needs  and  realities. 
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However,  AD/Cycle  is  not  the  full  story:  there  are  other  offerings  on  the 
IBM  platform,  as  well  as  considerable  activity  on  major  non-IBM  plat- 
forms (DEC,  Hewlett-Packard  and,  increasingly,  UNIX).  These  platform 
issues  will  be  discussed  further  in  Chapter  VI.  However,  several  general 
technology  trends  are  evident: 

Tool  Architecture:  On  the  IBM  platform,  the  transition  to  repository- 
based  integrated  tools  is  clear.  On  other  platforms,  linked  tools  have  not 
been  abandoned,  although  repositories  represent  one  thread  of  vendor 
strategies. 

Tool  Standards:  AD/Cycle  has  emerged  as  the  de  facto  standard  on  IBM 
platforms;  it  is  not  clear  whether  there  is  any  long-term  place  for  other 
standards  on  IBM  platforms.  This  raises  the  interesting  issue  whether 
vendors  such  as  Andersen  Consulting  (Foundation)  and  Texas  Instru- 
ments (lEF)  will  position  their  own  de  facto  standards  as  those  that  can 
bridge  heterogeneous  platforms  (see  Chapter  VI). 

It  is  even  possible  that  AD/Cycle  or  a  variant  could  emerge  as  a  de  facto 
standard  on  non-IBM  platforms.  This  possibility  has  been  raised  by  a 
major  CASE  vendor  that  is  not  part  of  the  AD/Cycle  inner  circle.  This 
could  occur  for  the  same  reasons  that  AD/Cycle  was  received  so  warmly 
by  the  IBM  user  community:  the  plethora  of  competing  pseudo-stan- 
dards in  the  non-IBM  world  is  certainly  as  frustrating  to  CASE  progress 
as  it  was  in  the  pre- AD/Cycle  IBM  environment. 

Methodologies:  So  far,  CASE  tool  vendors  have  taken  a  hands-off 
approach  to  specifying  particular  methodologies.  This  is  understandable, 
given  the  large  amount  of  work  that  even  now  remains  to  be  done  on  the 
core  CASE  technology  itself.  However,  as  the  repository-based  environ- 
ments become  more  mature,  the  logic  of  the  CASE  situation  will  almost 
certainly  impel  CASE  developers  to  make  choices: 

•  Even  now,  for  example,  AD/Cycle  is  endeavoring  to  make  the  repre- 
sentation in  its  repository  incorporate  both  the  object-oriented  and 
entity-relationship  modeling  approaches.  The  practical  effects  are  not 
fully  known. 

•  Many  of  the  differences  in  methodologies  are  ones  of  form,  not  content 
(arrowheads,  boxes,  etc.).  To  the  extent  that  these  differences  are 
abolished,  there  will  be  significant  savings  in  training  and  much  better 
communication  within  IS  departments  generally. 

•  On  a  strictly  pragmatic  level,  arbitrarily  selecting  any  one  methodology 
would  bring  considerable  benefits  in  terms  of  better  communication, 
more  efficient  training,  and  better  methodology-tool  linkage. 
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•  A  considerable  point  is  sometimes  made  of  "selecting  a  methodology  to 
meet  the  needs  of  an  organization."  This  becomes  suspect  on  closer 
inspection,  especially  if  one  recalls  that  the  same  point  was  made  until 
recently  concerning  the  selection  of  CASE  tools  themselves.  Few 
organizations  are  truly  different  enough  to  need  a  unique  methodology; 
even  fewer  have  the  resources  to  support  their  own  methodologies.  The 
acceptance  of  AD/Cycle  itself  has  shown  how  much  CASE  users  value 
uniformity  over  complexity. 

Exhibit  IV-8  summarizes  these  integration  trends  between  the  two  types 
of  platforms. 


Integraton  Trends — IBM  and  Non-IBM  Platforms 
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•  On  the  whole,  the  IBM  platform  is  one  step  ahead  of  the  non-IBM 
platforms  (assuming  one  accepts  the  logic  and  value  of  integration). 

•  To  the  extent  this  is  true,  then  the  previously  cited  vendor  comment  of 
AD/Cycle  having  a  potential  role  on  non-IBM  platforms  begins  to 
make  a  great  deal  of  sense: 

-  It  could  take  several  years  and  considerable  resources  for  an  IBM 
competitor  to  create  the  functional  equivalent  of  AD/Cycle. 
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-  Given  that  IBM's  AD/Cycle-related  costs  are  well  into  the  hundreds 
of  millions  of  dollars,  it  is  unlikely  that  any  other  vendor  can  do  so. 

-  Therefore,  adopting  as  much  of  AD/Cycle  as  possible  on  non-IBM 
platforms  would  be  extremely  logical.  IBM,  however,  would  not 
play  a  neutral  role  in  this  scenario  (see  Chapter  VI). 


Re-engineering  As  discussed  in  the  Definitions  section  of  Chapter  I,  there  are  several 

current  words  and  concepts  used  to  describe  the  re-engineering  process 
(re-engineering,  restructuring,  and  reverse  engineering)  in  addition  to 
older  terms  (e.g.,  corrective  maintenance,  adaptive  maintenance,  en- 
hancements, etc.)  There  is  not  yet  wide  agreement  within  the  industry  on 
the  precise  meaning  of  these  terms.  There  is  not  even  the  hint  of  loose 
consensus  that  exists  regarding  some  of  the  forward  engineering  terms. 

Until  recendy,  the  re-engineering  process  was  straightforward:  the 
objective  was  to  fix  an  application  and  sometimes  to  re-write  it;  this  was 
(and  is)  called  maintenance.  These  objectives  will  not  change,  since 
some  significant  element  of  data  processing  must  always  be  reactive  to 
outside  events  (including  program  failure).  However,  much  of  mainte- 
nance will  increasingly  be  viewed  as  re-engineering. 

Re-engineering  will  involve  two  basic  choices:  reverse  engineering  or 
re-use. 

Reverse-engineering  will  be  somewhat  analogous  to  maintenance  as  it  is 
now,  but  with  considerable  change  in  emphasis: 

•  Multiple  changes  over  time  will  increasingly  take  place  using  reverse- 
engineered  code  as  a  starting  point;  much  maintenance  now  is  treated 
as  if  it  were  a  one-time  occurrence,  even  if  similar  one-time  changes 
are  made  repeatedly. 

•  Reverse-engineered  applications  may  have  their  life  extended  dramati- 
cally. 

However,  the  full  potential  of  re-engineering  goes  beyond  the  reverse- 
engineering  and  preservation  of  a  particular  application.  Wider  re-use  of 
an  application's  constituents  should  prove  to  be  equally  valuable.  This 
re-use  can  include  the  following: 

•  At  the  minimum,  re-engineering  technology  can  be  used  to  understand 
the  processes  and  data  relationships  in  an  appHcation.  This  would  be 
done  preparatory  to  constructing  a  new  application.  For  efficient 
communication  the  re-engineering  and  forward  engineering  should  use 
the  same  conventions.  Consistent  conventions  are  needed  because  it 
may  turn  out  that  after  inspection,  the  logic  of  the  old  appHcation  might 
be  used  to  partially  populate  a  repository. 
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•  Populating  a  repository  from  the  logic  in  a  previously  written  applica- 
tion can  be  a  shortcut  as  well  as  a  means  of  preserving  the  data  process- 
ing "heritage"  of  an  organization. 

•  Finally,  much  larger  pieces  of  an  application  can  be  used  as  the  founda- 
tion for  constructing  an  updated  or  expanded  application. 

•  These  steps  form  a  continuum;  the  exact  strategy  to  be  followed  is  often 
not  finally  known  until  the  organization  is  fully  engaged  in  the  re- 
engineering  process. 

Exhibit  rV-9  provides  an  overview  of  these  re-engineering  options  de- 
scribed above. 


EXHIBIT  IV-9 
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The  extent  to  which  existing  applications  are  reverse  engineered  versus 
being  re-used  can  have  important  implications  for  individual  firms  and 
for  the  CASE  industry  as  a  whole: 

•  If  a  very  high  proportion  of  existing  applications  are  re-used,  then 
CASE  environments  that  are  forward-engineering  focused  (i.e..  Stage  3 
CASE)  will  be  less  useful.  (If  a  high  proportion  are  reverse  engi- 
neered, then  forward-only  tools  are  much  more  acceptable.) 

*  Where  a  firm  is  highly  committed  to  a  changed  technology  base  (e.g., 
client/server  or  enterprise  information  modeling),  then  re-engineered 
applications  would  only  be  cost-effective  where  short-term  benefits 
predominated. 

Exhibit  IV- 10  contrasts  the  different  factors  that  help  determine  whether 
re-engineered  or  re-used  applications  would  be  most  appropriate. 
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Both  vendors  and  IS  departments  realize  the  importance  of  re-engineer- 
ing; both  indicate  that  there  is  a  significant  gap  between  the  importance 
they  place  on  re-engineering  and  their  knowledge  of  it  (Exhibit  IV- 1 1). 
In  this  area,  the  gap  is  even  wider  on  the  vendors'  side;  this  appears  to  be 
because  more  vendors  have  already  awakened  to  the  implications  of 
Stage  4  CASE,  its  requirements,  and  its  opportunities. 


Importance  and  Knowledge  of  Re-engineering  for 
Vendors  and  IS  Departments 
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Integrating  re-engineering  with  the  rest  of  CASE  will  occur  in  phases,  as 
shown  in  Exhibit  IV- 12. 

•  The  integration  of  forward-engineering  components  is  well  underway 
(Phase  1). 

•  Work  is  now  in  process  by  several  vendors  (Viasoft,  Language  Tech- 
nology, IBM,  and  others)  to  take  current  standalone  back-end  re- 
engineering  tools  and  link  them  to: 

-  A  self-contained  front  end  (within  re-engineering;  Phase  2) 

-  The  back  end  of  forward-engineering  tools  (Phase  3) 

•  Once  there  is  a  self-contained  front  end/back  end  within  re-engineering 
(Phase  2),  then  it  would  be  feasible  to  tie  the  front  end  of  re-engineer- 
ing to  the  front  end  of  forward  engineering  (Phase  4).  This  would  close 
the  loop  and  begin  to  fully  integrate  forward  engineering  and  re-engi- 
neering. 
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EXHIBIT  IV-12 
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In  1991  INPUT  expects  a  minimal  amount  of  maintenance,  modification, 
redevelopment  and  new  development  to  be  performed  using  re-engineer- 
ing tools.  This  low  usage  is  due  to  a  lack  of  critical  mass  in  re-engineer- 
ing: 


•  Maturing  tools  that  are  still  essentially  standalone  tools 

•  Re-engineering  sponsorship  by  small  vendors 

•  Lack  of  sponsorship  by  IBM 

•  Few  methodologies;  none  widely  accepted 

•  Little  training  available  or  used 

•  Low  management  priority  given  to  maintenance 

By  1996  INPUT  expects  this  picture  to  have  turned  around  markedly — 
essentially  because  all  (or  most)  of  the  factors  above  will  have  been 
reversed.  Chapter  V  provides  INPUT  forecasts  in  this  area. 


Distributed  The  term  distributed  applications  is  often  shorthand  for  one  or  both  of 

Applications  these  computer  environments: 

•  SQL-based  inquiry  services 

•  Client/server  architecture — usually,  although  not  necessarily,  limited  to 
high-end  PCs  and  workstations  in  a  LAN  environment. 
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These  environments  are  perfectly  adequate  for  supporting  analysis  func- 
tions dispersed  through  an  organization: 

•  Data  is  passed  from  one  data  base  (server)  to  another  (client). 

•  Precise  data  synchronization  is  not  required,  or  daily/weekly  synchroni- 
zation is  adequate. 

•  Work  unit  errors  in  programming,  processing  logic,  security,  etc.  are 
not  critical  and/or  are  the  responsibility  of  the  work  unit. 

The  requirements  in  a  transaction-driven,  distributed  application  are  quite 
different: 

•  Where  data  is  shared,  changes  in  states  must  be  simultaneous  or  occur 
under  defined  circumstances. 

•  Data  locking  and  security  is  of  the  utmost  importance. 

This  situation  is  even  more  critical  where  different  processing  locations 
are,  essentially,  peers.  They  will  often  have  overlapping  processing  and 
data  base  responsibilities  (application  domains),  as  illustrated  in 
Exhibit  IV-13. 

•  The  domains  marked  "A"  are  conventional  applications  operating  on  a 
single  host  (whether  they  supply  workstations  with  data  is  a  secondary 
issue  from  a  design  and  implementation  standpoint). 

•  The  domain  marked  "B"  is  an  intermediate  form  of  distributed  applica- 
tion. 

-  One  of  the  peers  may  serve  as  host,  delegating  and  controlling  pro- 
cessing logic;  data,  where  decentralized,  is  synchronized  and  con- 
trolled by  the  host. 

-  An  alternative  arrangement  is  for  the  two  peers  to  be  equal,  with 
event-driven  synchronization  as  in  real-time  systems. 

•  The  domain  marked  "C"  (and  the  other  overlapping  domains)  repre- 
sents complexity  of  a  much  higher  order.  A  particular  section  of  an 
application  may  interact  with  one  or  more  apphcations. 

Currently,  CASE  is  impHcitly  aimed  at  "A"-type  applications  (as  identi- 
fied in  Exhibit  IV-13).  As  progress  is  made  in  understanding  and  dealing 
with  the  issues  of  distributed  data  bases  in  a  transaction  environment, 
CASE  will  become  increasingly  applicable  to  "B"-type  applications. 
"C"-type  applications  are  a  somewhat  different  issue: 
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Application  Domains  and  Multiple  Peers 
(Schematic) 


(a) 

®Q  _ 

1/ 

^  ® 

Processing  Location 


^   Application  Domain 

A  =  Single  application,  single  host 
B  =  Single  application,  multiple  peers 
C  =  Multiple  applications  and  peers 


•  Once  "B"-type  distributed  data  bases  function  adequately,  it  probably 
only  requires  a  series  of  incremental  technical  steps  to  be  able  to 
handle  "C'-type  applications. 

•  CASE  tools  could  also  undergo  these  incremental  changes  reasonably 
quickly. 

•  However,  in  INPUT'S  view,  the  sticking  point  will  not  just  be  the 
technical  aspects,  but  also  the  human  aspects: 
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-  CASE  technology  is  an  enormous  help  in  keeping  track  of  applica- 
tions relationships.  Ultimately,  though,  human  beings  must  under- 
stand these  relationships;  even  if  a  few  key  systems  designers  were 
able  to  accomplish  this,  it  is  unlikely  that  business  users  would  be 
able  to  (in  the  sense  of  having  sufficient  interest  or  time). 

-  Wherever  possible,  then,  distributed  applications  should  be  kept 
separate,  or  at  most,  exchange  data  and  other  information  at  a  few 
shaiply  defined  points. 

-  Otherwise,  the  intersections  of  complex  systems  may  sometimes 
require  going  outside  the  CASE  framework  for  analysis  and  imple- 
mentation. This  will  undermine  some  of  the  rationale  for,  and  ben- 
efits of,  CASE. 

Exhibit  rV-14  summarizes  the  issues  concerning  application  domains 
"A,"  "B,"  and  "C." 

With  this  background,  it  is  not  surprising  that  both  vendors  and  IS  depart- 
ments place  great  importance  on  having  CASE  support  for  distributed 
applications  (Exhibit  IV- 15). 

•  Both  see  a  significant  gap  between  importance  and  knowledge. 

•  The  gap  is  considerably  wider  for  vendors:  they  rate  the  importance 
higher  and  their  knowledge  lower. 

The  very  large  and  significant  gap  on  the  vendor  side  is  another  argument 
strongly  against  any  immediate  and/or  previously  unannounced  solutions 
appearing. 
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EXHIBIT  IV-14 


Application  Domains  and  Peer  Processing 


A* 
Single 
Application/ 
Sinale  Host 

B* 
Single 
Application/ 
Multiole  Peers 

C* 
Multiple 
Applications/ 
Multiple  Peers 

Processing 
Elements 

•  All  processing  on 
host  (mainframe  or 
functional 
equivalent) 

•  Centralized  logic 
design 

•  Processing  may  be 
delegated 

•  Event-driven 
processing  may  be 
utilized 

•  Single  central  design 
control  difficult  to 
achieve  and  maintain 

•  Design  and 
implementation  highly 
localized 

•  Event-driven 
processing 

Data 
Elements 

•  Centralized  data 

•  Single  DBMS 
control  (for 
operations/ 
transactions) 

•  Downloaded  data 
for  local  analysis 

•  Data  may  be 
decentralized 

•  If  decentralized,  may 
be  synchronized 
and/or  controlled  by 
one  peer 
(temporary  "host") 

•  Some  secondary  may 
be  under  jurisdiction 
of  only  one  peer 

•  Decentralized  data  is 
norm 

•  Event-driven  data 
synchronization 

•  Critical  data  under 
central 
jurisdiction 

*  Letter  refers  to  domains  illustrated  in  Exhibit  IV-13 
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EXHIBIT  IV-15 


Importance  and  Knowledge  of  CASE  Support  for 
Distributed  Applications  for  Vendors  and  IS 
Departments 


Vendors 


IS  Departments 


Wi  Importance 
□  Knowledge 


5 

High 


E 


Resolution  of 
Technical  Issues 


The  critical  technical  issues  as  identified  by  INPUT'S  research  and 
discussed  earlier  are: 

•  Integration  and  standards 

•  Re-engineering 

•  Distributed  applications 

1.  Integration 

In  the  near  term  (i.e.,  through  approximately  1993)  the  direction  of 
integration  from  a  practical  standpoint  will  be  synonymous  with  AD/ 
Cycle,  its  success  and  acceptance.  From  information  currently  available, 
AD/Cycle  stands  a  very  good  chance  of  meeting  its  (and  its  customers') 
objectives  (Exhibit  rV-16). 

An  area  where  there  is  still  some  doubt  is  a  semi-technical  issue:  how 
fast  can  AD/Cycle  be  absorbed,  by  individuals  and  by  an  organization  as 
a  whole? 


•  Face-to-face  training  will  not  be  enough.  There  are  not  enough  quali- 
fied people  available  to  staff  for  the  intensive  and  extensive  levels  of 
training  required. 
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Probability  of  AD/Cycle  Meeting  Customer 
Requirements  (In  1991-1993  Period) 


Issue 

Probability 

Maintaining  schedule 

High 

Meeting  current  design 
specifications 

High 

Developing  successful  vertical 
information  models 

High 

Ability  to  handle  very 
large  models 

Medium/High 

Ability  to  handle  very  complex 
models 

Medium/High 

Development  of  scalable 
learning  techniques 

Medium 

•  "Scalable  learning  techniques"  will  be  required,  i.e.,  high-quality 
training  for  large  numbers  of  people  at  different  qualification  levels. 

•  This  could  represent,  at  last,  an  area  where  interactive  video  training 
could  come  into  its  own. 

Unfortunately,  it  is  only  just  now  becoming  clear  what  training  needs 
(and  budgets)  will  be. 

•  Since  AD/Cycle  (even  in  the  Knowledge  Ware  version)  is  relatively 
new,  the  exact  dimensions  of — and  technical  solutions  to — training 
needs  are  not  yet  clear. 

•  In  any  event,  the  "early  adopters"  are  probably  not  representative  of  the 
bulk  of  the  CASE  user  population. 
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2.  Standards 

AD/Cycle  has  quickly  emerged  as  the  de  facto  IBM  platform  standard.  It 
is  unlikely  that  any  other  standard  will  exist  on  the  IBM  platform  before 
the  mid-1990s: 

•  IBM  would  have  little  incentive  to  make  the  totality  of  AD/Cycle  into 
an  ANSI  standard  because  it  would  then  lose  control  over  a  strategic 
resource  (see  Chapter  VI). 

•  By  the  same  token,  other  vendors  would  be  equally  unwilling  to  see 
AD/Cycle  become  a  formal  standard  because  this  would  cede  control 
over  a  strategic  area  to  IBM. 

As  other  vendors  have  absorbed  the  full  meaning  of  AD/Cycle,  they  have 
also  understood: 

•  AD/Cycle  has  pre-empted  the  attention  of  most  business  application 
developers. 

•  An  AD/Cycle-like  environment  costs  a  lot  to  develop,  in  terms  of 
dollars,  dme,  and  skilled  personnel. 

•  There  may  be  niches  (perhaps  even  very  large  niches)  left  unfilled  by 
AD/Cycle;  however,  these  will  not  be  very  evident  undl  1993,  after  the 
reality  of  AD/Cycle  has  become  clear. 

ConsequenUy,  there  is  very  litde  chance  of  alternative  de  facto  standards 
emerging  in  the  IBM  environment  in  the  next  five  years,  and  only  a 
slightly  better  chance  in  non-IBM  environments. 

The  most  interesting  area  to  consider  is  whether  standards  will  develop 
for  defining  CASE  across  different  vendors'  hardware  and  software 
platforms.  Several  individual  vendors  are  moving  in  that  direction  (e.g., 
Andersen,  Texas  Instruments,  and  Index).  However,  a  multiplicity  of 
efforts  will,  after  a  time,  impede  rather  than  accelerate  acceptance  (as  in 
Stage  2  CASE  generally). 

Cross-platform  standards,  therefore,  are  mostly  a  business  and  comped- 
tive  issue.  Consequently,  in  spite  of  a  need  for  cross-vendor  CASE 
environments,  INPUT  sees  only  a  medium  chance  of  this  kind  of  standard 
emerging  over  the  next  five  years. 

Exhibit  rV-17  summarizes  the  preceding  analysis. 
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U.S.  CASE  Standards  Scenarios  (To  1996) 


Standards  Issue 

Probability 

AD/Cycle  as  de  facto 
standard 

High 

Development  of  formal 
standards 

Medium/Low 

Alternate  (de  facto)  standards 

•  In  the  IBM  environment 

•  In  other  environments 

Low 

Medium/Low 

Development  of  cross-platform 
standards  (Hardware/Software) 

Medium 

Source:  INPUT  assessment 


3.  Re-engineering 

The  issues  involved  in  re-engineering  are  summarized  in  Exhibit  IV- 12: 
How  likely  is  each  phase  to  become  a  reality  by  1993? 

•  Phase  1  (back  end  to  front  end  within  forward  engineering)  is  a  virtual 
certainty.  However,  in  and  of  itself,  this  will  provide  marginal  assis- 
tance because  it  will  only  be  useful  in  day-one-forward  applications. 

•  Phase  2  (back  end  to  front  end  within  re-engineering)  also  has  a  high 
probability  of  being  achieved. 

•  Phase  3  (back  end  to  back  end)  is  somewhat  more  difficult,  since 
current  back-end  re-engineering  products  have  their  own  approach  and 
architectures  that  are  not  now  compatible  with  forward-engineering 
products. 

•  Phase  4  (front  end  to  front  end)  is  dependent  on  the  successful  comple- 
tion of  the  prior  step.  This  involves  planning  on  the  re-engineering 
side  so  that  the  front-end  environments  are  similar. 

Exhibit  IV- 18  summarizes  these  evaluations. 
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EXHIBIT  IV-18 


Probability  of  Resolving  Re-engineering 
Issues  by  1993 


f  ^   _ 

Issue 

Exhibit  IV-12 
Reference 

Probability 

Back-end  to  front-end  (within 
forward  engineering) 

Phase  1 

Very  High 

Back-end  to  front-end  (within 
re-engineering) 

Phase  2 

High 

Back-end  to  back-end  (from 
re-engineered  code  to  forward 
engineering  environment) 

Phase  3 

Medium 

Front-end  to  front-end  (from 
re-engineering  to  forward 
engineering  environment) 

Phase  4 

Medium  to  high 
(once  phase  2 
completed) 

4.  Distributed  Application  Development 

The  key  issue  involving  distributed  applications  is  when  and  if  the  under- 
lying distributed  data  base  technology  will  be  complete;  this  is  not  a 
CASE  issue,  per  se,  but  it  is  critical: 

•  Without  progress  in  the  underlying  distributed  data  base  technology, 
applications  development  in  this  environment  will  obviously  be  very 
constrained. 

•  The  schedule  for  CASE  appearing  in  a  distributed  environment  is 
consequently  a  lengthy  one.  If  the  time  horizon  for  re-engineering  is 
1993,  the  horizon  for  distributed  applications  development  is  twice  that, 
i.e.,  1996. 

Distributed  development  issues  will  probably  be  methodology  driven; 
that  is,  what  should  analysis  and  design  consist  of  in  a  distributed  envi- 
ronment? In  that  case,  what  is  the  likelihood  of  the  increasingly  complex 
domain/peer  relationship  described  in  Exhibits  IV- 13  and  IV- 14  becom- 
ing thoroughly  understood? 
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•  INPUT  believes  there  is  a  reasonable  chance  of  a  single-application/ 
single-host  methodology  being  developed  by  1996  (although  almost 
certainly  toward  the  end  of  that  period). 

•  On  the  other  hand,  there  is  a  low  likelihood  of  multiple  application/ 
multiple  peer  issues  being  resolved  by  that  time. 

Exhibit  IV- 19  summarizes  INPUT'S  analysis. 


Probability  of  Resolving  Distributed 
Application  Issues  by  1996 


Issue 

Probability 

Distributed  data  base  segmentation 
and  control  (non-CASE  issues) 

Medium 

Distributed  design 
methodology  developed 

•  Single  application/host 

Medium  (dependent 
on  preceding) 

•  Single  application/multiple  peers 

Low 

•  Multiple  applications/multiple  peers 

Very  low 

Note:  For  a  graphical  representation  of  the  issues,  see  Exhibit  IV-13. 


Source:  INPUT  Assessment 
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Market  Forecast 


A  

Overview  Market  forecasts  are  sometimes  viewed  as  being  primarily  of  interest  to 

vendors.  In  this  case,  the  forecast  and  its  rationale  is  at  least  as  important 
to  IS  departments: 

•  INPUT  has  provided  a  series  of  analyses  on  individual  components  of 
CASE  growth  and  associated  probabilities.  These  can  serve  as  check- 
points against  which  to  measure  future  developments. 

•  Some  individual  IS  departments  may  differ  from  the  norm — their 
potential  may  be  for  either  faster  or  slower  growth.  These  firms  should 
compare  their  specific  situations  against  the  general  environment. 

;  The  CASE  product  market  is  still  one  that  is  relatively  immature.  Be- 
cause of  this,  the  CASE  product  market  is  far  more  subject  to  variables 
than  more  mature  markets.  Because  of  the  multiple  variables  affecting 
this  market,  INPUT  has  prepared  its  market  forecast  to  reflect  alternate 
scenarios. 

,   The  first  section  of  this  chapter  provides  a  near-term  and  medium-term 
1   situation  analysis  of  the  significant  market  and  technical  factors.  This 
analysis  draws  on  the  contents  of  the  two  previous  chapters. 

•  The  situation  analysis  provides  the  rationale  for  the  quantitative  fore- 
casts. 

•  The  multiple  scenario  approach  permits  readers  who  wish  to  make 
different  sets  of  assumptions  to  set  up  their  own  sensitivity  analysis  for 
assessing  the  impact  of  individual  market  factors. 

The  resulting  market  forecast  will  be  of  obvious  use  and  interest  to 
software  product  vendors.  The  figures,  and  especially  the  reasoning 
behind  them,  should  be  important  to  other  vendor  groups  as  well. 
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•  The  quantity  and  intensity  of  CASE  use  is  one  of  the  prime  drivers  of 
the  forecast.  There  is  no  information  service  vendor  or  IS  department 
that  will  not  be  affected  in  the  1990s  if  CASE  growth  is  explosive. 

•  IS  planners  must  monitor  CASE  futures  very  carefully:  overoptimism 
or  overpessimism  could  be  equally  dangerous. 

If  CASE  achieves  a  fast  take-off,  many  areas  will  be  affected  in  both 
corporations  and  vendors  (Exhibit  V- 1). 


EXHIBIT  V-1 


Impact  of  CASE  Take-Off 


Potential 

Corporations 

Software  Products  Vendors 

Impact  On 

Planners 

Appl. 
Dev. 

User 
Depts. 

CASE 
Products 

Other 
Sys.  SW 

Appl. 
SW 

Prof.  Svc./ 
Sys.  Int. 

Manner  in  which  work  is 
conducted  (tactics) 

// 

// 

// 

/ 

/ 

// 

Organizational  structure 

/ 

// 

// 

✓ 

Future  role  of  organization 

/ 

// 

/ 

// 

/ 

✓/ 

✓/ 

Business  strategy 

✓/ 

// 

// 

✓/ 

// 

// 

=  Important  Impact 
//  =  Very  Important  Impact 


•  The  impact  on  application  developers  and  CASE  product  vendors  is 
self-evident. 

•  However,  user  departments  could  be  affected  at  least  as  much  since 
they  could  depend  on  IS  to  achieve  much  more  than  at  present.  Rela- 
tionships would  change  as  well. 

•  The  business  strategies  of  corporations  as  well  as  most  information 
service  vendors  would  need  to  be  re-examined  closely. 

•  Specific  vendor  impacts  are  analyzed  in  greater  depth  in  Chapter  VI. 
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Situation  Analysis 


1.  Near-Term  Issues  (1991-1993) 


There  are  two  sets  of  near-term  issues  affecting  market  growth: 

•  Technology-related  issues 

•  The  "soft"  issues  (described  in  Exhibit  III- 10),  which  affect  the  extent 
to  which  an  organization  is  ready  ("organizational  readiness")  to  absorb 
and  make  productive  use  of  CASE. 

Based  on  INPUT'S  research,  these  organizational  readiness  issues  are 
even  more  important  than  the  technology  issues.  Exhibit  V-2  contains 
input's  assessment  of  a  number  of  the  organizational  readiness  issues 
for  both  1991  and  1993  (a  best-  and  worst-case  assessment  is  provided 
for  1993). 

•  The  sum  of  the  "grades"  for  1991  reflects  near  failure.  This  puts  into 
perspective  the  earlier  findings  on  the  overall  relative  ineffectiveness  of 
CASE  (e.g..  Exhibit  in-3). 

•  The  sheer  number  of  such  factors  needing  improvement  will  make 
progress  relatively  difficult;  yet  all  the  factors  are  important,  and  it  is 
difficult  to  make  a  case  that  some  can  be  ignored  at  the  expense  of 
others. 

•  The  worst-case  total  for  1993  shows  little  improvement  over  1991. 

•  The  best-case  total  would  virtually  guarantee  CASE  success  in  a  wide 
variety  of  settings. 

INPUT  concludes  that  in  the  near  term,  organizational  readiness  may 
serve  as  the  most  serious  constraint  to  CASE  progress. 

If  AD/Cycle  is  taken  as  a  surrogate  for  overall  technical  progress,  then 
near-term  CASE  technical  issues  are  not  serious  barriers  to  progress  (for 
a  summary,  see  Exhibit  IV- 16). 

Exhibit  V-3  describes  four  possible  near-term  scenarios  for  CASE  growth 
and  acceptance  (i.e.,  success).  Other  possibilities  have  not  been  analyzed 
in  depth  since  they  represent,  in  INPUT'S  opinion,  combinations  of  very 
unlikely  events: 

•  CASE  software  technology  standing  by  itself  is  already  beyond  the  low 
probability  of  success  stage  (Region  I). 

•  It  is  quite  unlikely  that  organizational  readiness  will  be  at  a  higher  stage 
of  development  relative  to  CASE  technology  (Region  II). 
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EXHIBIT  V-2 


CASE  Organizational  Readiness  Factors: 
1991  and  1993 


1993 

Factor 

1  yyi 

Worst 

Best 

Culture/organization  changes 

•  Understanding  of  general  issues 

c- 

C 

B+ 

•  Specific  environment  issues 

C- 

C 

A 

Methodologies 

•  Evaluation  criteria 

C 

p 

A 
r\ 

•  Integration  into  specific 
environment 

C 

C 

B+ 

Measurement 

•  Definition  of  success 

F 

n 

C+ 

•  Conducting  measurements 

D- 

D- 

B- 

Implementation 

•  Understanding  success/ 
failure  factors 

D 

C- 

B+ 

•  Planning 

C- 

c- 

B+ 

•  Applying  success  factors  to 
specific  environment 

D 

c- 

B+ 

IS-User  Relationships 

•  General  requirements 

C- 

c 

B+ 

•  Specific  restructuring 

C 

c 

B+ 

Training 

•  Understanding  general  needs 

C- 

c+ 

B+ 

•  Developing  methodologies 

D 

D 

A 

Source:  INPUT  Assessment 
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Near-Term  (1991-1993)  CASE  Success 
Determinants:  Alternate  Scenarios 


CASE 

Software 

Technology 

Readiness 

(Probability) 


Low  —  ►  High 


Organizational  Readiness  (Probability) 
0  Unlikely  Events 
Scenarios 


•  High  technical  success  would  almost  certainly  have  a  "drag-along" 
effect  on  organizational  readiness.  For  example,  CASE  tools  that  were 
relatively  easy  to  use,  incorporated  self-training  features,  and  used 
proven  templates  would  be  accepted  in  more  organizations  sooner.  The 
effect  would  be  that  high  technological  readiness  would  not  be  associ- 
ated with  low  organizational  readiness  (Region  III). 

Exhibit  V-4  spells  out  the  individual  scenarios  and  assigns  a  probability 
with  an  accompanying  rationale. 

•  INPUT  has  been  impressed  with  the  recent  progress  made  in  the  under- 
lying CASE  technology  generally  (i.e.,  not  limited  to  AD/Cycle). 
These  technology  improvements  will  encourage  user  organizations  to 
take  CASE  more  seriously.  Current  CASE  technology  will  help  estab- 
lish wider  CASE  principles  in  customer  organizations  (Scenario  B). 


0 1991  by  INPUT.  Reproduction  Prohibited. 


V-5 


THE  FUTURE  OF  CASE:  1991-1996 


INPUT 


EXHIBIT  V-4 


Evaluation  of  Near-Term  CASE  Success  Scenarios 


Success  Combination 

Rationale 

Scenario 

Technology 

Organizational 

Probability 

A 

Medium/ 
Low 

Low 

.25 

Technology  success  is  likely  to  be  at 
least  medium/high 

B 

Medium/ 
High 

Medium 

.50 

This  level  of  technical  success  is 
quite  likely;  some  organizational 
readiness  "drag-along"  by  CASE 
technology  likely 

C 

High 

Medium/ 
High 

.15 

Organizational  readiness  will  be  a 
bottleneck 

D 

High 

High 

.10 

Organizational  readiness  will  be 
a  severe  bottleneck 

•  A  less  attractive  combination  is  shown  in  Scenario  A,  where  neither 
technical  progress  nor  organizational  readiness  are  as  good.  There  is 
even  a  chance  that  Scenario  B  could  turn  into  Scenario  A — i.e.,  nega- 
tive experiences  of  early  users  could  reduce  the  number  of  organiza- 
tions that  believed  they  were  ready  for  CASE. 

•  Scenarios  C  and  D  are  very  positive  ones:  the  technology  makes 
widely  perceived  breakthroughs  and  increases  organizational  readiness. 
INPUT  believes  that  it  will  be  difficult  for  very  many  user  organiza- 
tions to  make  their  own  unassisted  breakthroughs.  So  far,  there  are 
very  few  outside  organizations  (consultants  and  vendors)  that  have 
focused  on  offering  support  services  to  help  make  breakthroughs. 

2.  Medium-Term  Issues  (1994-1996) 

In  the  medium  term,  the  organizational  readiness  factors  will  continue  to 
be  important. 

•  The  near-term  progress  (or  lack  of  progress)  will  heavily  influence  the 
impact  in  the  1994-1996  period. 
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•  If  near-term  organizational  readiness  progress  is  very  slow,  the  progno- 
sis for  1994-1996  will  be  of  continued  slow  progress. 

The  technical  issues  will  become  more  important  during  this  period: 

•  If  re-engineering  issues  are  resolved  on  the  timescale  shown  in  Exhibit 
IV- 18,  then  re-engineering  is  likely  to  become  an  important  CASE 
factor  during  this  period. 

•  Distributed  application  development  is  less  likely  to  be  supported 
(Exhibit  IV- 19). 

Therefore,  a  key  question  is  the  relative  importance  of  re-engineering 
versus  distributed  development  during  the  next  five  years. 

These  issues  revolve  around  the  kinds  of  applications  development 
environments  that  exist  now,  compared  to  the  likely  environments  that 
will  exist  in  1996.  For  this  analysis,  INPUT  has  drawn  on  research 
performed  in  the  last  six  months  across  several  of  its  programs  (details  in 
Chapter  I). 

3.  New  versus  Maintenance  Activities 

Currently,  new  development  and  maintenance  activities  each  account  for 
about  40%  of  application  development  activities.  The  remainder  are 
modifications,  i.e.,  something  more  than  fixes,  but  less  than  full-scale 
new  development. 

The  boundaries  between  these  activities  are  notoriously  fuzzy — there  are, 
for  example,  fewer  and  fewer  "new"  applications  that  do  not  build  at  least 
to  some  degree  on  what  has  gone  on  before. 

By  1996,  the  basic  conceptual  distinctions  between  new  development  and 
maintenance  activities  will  still  exist;  however,  re-engineering  concepts 
and  practices  will  have  taken  serious  hold  by  then: 

•  Almost  half  of  maintenance  activities  will  consist  of  re-engineered 
applications  (using  the  distinctions  developed  in  Exhibit  IV-9). 

•  At  least  half  of  "new"  development  will  build  on  consciously  re-used 
applications. 

The  distinctions  between  new,  maintenance,  and  enhancement  activities 
will  become  even  less  precise  in  five  years,  in  large  part  because  of  re- 
engineering.  Exhibit  V-5  illustrates  these  changes. 
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New,  Maintenance  and  Enhancement  Activities: 

1991-1996 


Reverse- 
engineered  Reused 


0  20  40  60  80  100 

E3  Maintenance 

^  Enhancements 

□  New  Development 


To  the  extent  re-engineering  is  made  easier,  more  correct,  and  more 
efficient  by  using  CASE  products,  then  the  CASE  market  will  be  able  to 
grow  at  a  faster  rate.  If  customers  are  forced  to  use  unintegrated  tools, 
with  gaps  between  tools  and  some  tools  performing  suboptimally,  then 
this  part  of  the  CASE  market  will  show  lower  growth. 

4.  Host-Based  versus  Multiple  Peer  Activities 

INPUT  estimates  that  close  to  three-quarters  of  development  resources 
are  now  devoted  to  host-based  applications;  this  will  fall  to  a  little  over 
half  by  1996  (Exhibit  V-6). 

•  Host-led  applications  work  will  increase  moderately. 

•  Work  on  multiple  peer  applications  will  more  than  double  (although 
starting  from  a  modest  7%  in  1991). 

INPUT  estimates  that  only  half  of  new  development  consists  of  classic 
host-based  development. 
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Host-Based,  Host-Led  and  Multiple  Peer 
Development:  1991-1996 


1991 


1996 


0  20       40       60       80  100 

□  Host-Based 
^  Host-Led 

□  Multiple  Peer 


•  Almost  all  of  the  rest  conforms  to  the  "host-led"  model  (described  in 
Chapter  HI),  typically  a  host  performing  most  processing,  supported  by 
PCs  to  which  well-defined  functions  have  been  decentralized. 

•  Only  a  small  amount  of  new  work  is  aimed  at  true  multiple  peer  envi- 
ronments, usually  involving  linked  workstations. 

Each  of  these  environments  generates  maintenance/enhancements,  with 
the  great  majority,  not  surprisingly,  directed  at  more  tiaditional  environ- 
ments. 

INPUT  expects  the  picture  to  change  markedly  by  1996. 

•  Multiple  peer  environments  will  account  for  a  majority  of  new  develop- 
ment that  does  not  involve  the  use  of  re-used  applications. 

•  Half  of  host-led  applications  will  involve  upgrading  older  applications 
via  re-used  code. 
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Exhibit  V-7  summarizes  INPUT'S  view  as  to  the  distribution  of  types  of 
development  by  application  focus. 


EXHIBIT  V-7 


Changes  in  Type  of  Development  by  Application  Focus: 

1991-1996 

Type  of  Development 


Host-Based         Host-Led        Multiple  Peer 


Source:  Appendixes  E&F 
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•  The  new  development  and  host-based  axes  together  account  for  over 
90%  of  activities.  This  seems  to  bode  well  for  the  focus  of  current 
CASE  tools. 

•  In  reality,  however,  CASE  is  now  focused  on  host-based  new  develop- 
ment (and,  to  a  degree,  on  host-led  new  development). 

•  This  is  a  quantitative  indication  of  the  existing  importance  of  the  re- 
engineering  market  and  the  extent  to  which  it  is  not  being  served. 


In  1991,  about  one-third  of  application  development  could  use  CASE 
tools.  By  1996,  potential  CASE  focus  will  have  almost  doubled.  Even 
more  important,  the  greatest  need  and  opportunity  will  be  in  the  re- 
engineering  areas. 

Even  if  CASE  does  not  have  much  to  offer  multiple  peer  applications  and 
they  still  have  to  be  built  the  "old-fashioned  way,"  this  will  only  be  a 
secondary  issue  to  vendors  and  most  IS  organizations. 

This  highlights  the  importance  of  re-engineering  to  CASE  users  and 
CASE  vendors. 

2.  CASE  Product  Growth 

As  discussed  at  the  beginning  of  the  chapter,  the  CASE  market's  future 
growth  will  be  heavily  affected  by  the  following: 

•  Near-term  considerations  will  be  heavily  influenced  by  organizational 
readiness. 

•  Medium-term  growth  will  be  greatly  influenced  by  developments  in  re- 
engineering  techniques. 

Exhibit  V-8  (and  its  backup,  Exhibit  V-9)  show  the  three  scenarios: 

•  INPUT  considers  the  middle  scenario  the  most  likely:  adequate,  but 
not  maximum,  progress  in  organizational  readiness  and  re-engineering. 

•  The  "low"  scenario  essentially  encompasses  a  lack  of  further  advances 
in  CASE.  CASE  will  continue  to  grow  but  in  a  non-strategic  mode  that 
is  oriented  mainly  to  technical  staff. 

•  The  "high"  scenario  assumes  that  both  the  "soft"  and  "hard"  issues  are 
resolved  satisfactorily.  Growth  might  in  fact  be  even  higher  if  not  for 
limitations  in  training,  staffing,  and  the  general  ability  of  organizations 
to  absorb  CASE  techniques. 


c 


Forecasts 


1.  Application  Environment  Forecasts 
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CASE  Product  Growth  Scenarios:  Summary 

CAGR 

High 

(Percent) 
34 

2000 

Most  Likely 

Ilions 

1500 

— 

Low  / 

^  22 

1000 

— 

13 

500 

0 

1        1        1        1  1 

1  1 

1990 

1991    1992  1993    1994  1995 

1996 

Source: 

Exhibit  V-9 

CASE  Product  Growth  Scenarios:  Summary 


Scenarios 

Low 
($  M) 

Growth 
(Percent) 

Mid 
($  M) 

Growth 
(Percent) 

High 
($  M) 

Growth 
(Percent) 

1990 

390 

390 

390 

1991 

450 

15 

450 

15 

450 

15 

1992 

495 

10 

540 

20 

585 

30 

1993 

545 

10 

645 

20 

815 

40 

1994 

625 

15 

810 

25 

1,140 

40 

1995 

720 

15 

1,010 

25 

1,600 

40 

1996 

830 

15 

1,260 

25 

2,240 

40 
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Competitive  Environment 


A  

AD/Cycle  Dominance    As  indicated  in  Chapters  III  and  IV,  AD/Cycle  has  been  welcomed  by 

both  users  and  vendors  as  offering  a  potentially  fully  integrated  tool  that 
will  serve  as  a  de  facto  standard  in  the  business  application  market.  This 
is  also  shown  in  market  measures  (see  Exhibit  VI- 1). 

•  IBM  carefully  chose  the  "close  vendor  partners"  in  which  it  has  made 
equity  investments:  products  from  IBM,  Knowledge  Ware,  Index 
Technology,  or  Bachman  Information  Systems  are  currently  repre- 
sented at  three-quarters  of  the  sites  interviewed. 

•  This  shows  impressive  power  for  the  AD/Cycle  family,  even  if  allow- 
ances are  made  for  the  following  situations: 

-  Products  purchased  only  for  R  &  D  and  comparison  purposes 

-  Products  purchased  but  never  used 

•  Even  more  impressive  is  that  25%  of  the  sites  planned  to  install  AD/ 
Cycle.  Note:  The  (unprompted)  responses  were  not 
"Knowledge Ware"  or  "Index,"  but  "AD/Cycle";  this  indicates  the 
power  of  IBM's  marketing  as  well  as  its  product  concept. 

Both  vendors  and  users  rate  the  importance  of  AD/Cycle  highly,  although 
for  vendors,  AD/Cycle  is  of  almost  overwhelming  importance  (Exhibit 
VI-2).  Interestingly  enough,  AD/Cycle  is  one  area  where  users  are 
reasonably  satisfied  with  their  current  level  of  knowledge. 

•  This  is  a  tribute  to  IBM's  educational  efforts  as  well  as  the  widespread 
discussion  in  the  trade  press  and  at  seminars. 

•  INPUT  believes  that  the  vendor  gap  shown  between  importance  and 
knowledge  may  be  a  more  realistic  position,  given  that  there  are  still 
many  unknowns  associated  with  AD/Cycle. 
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EXHIBIT  VI-1 


AD/Cycle's  Market  Share 


Current  CASE  Products 


IBM  and  Close 
Vendor  Partners 


All  Other  Vendors 


0       20       40       60  80 
Percent  of  Sites 

Planned  CASE  Products 


AD/Cycle 


All  Other  /  ^ 
Products  / 


25 


0  20 


40  60  80 
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100 


100 


Vendors  show  strikingly  less  interest  in  non-AD/Cycle  products 
(Exhibit  VI-3). 

•  This  bears  out  conversations  with  vendors,  where  the  only  two  topics 
of  conversation  were  their  own  products  and  AD/Cycle. 

•  The  user  profile  was  quite  similar  to  that  for  AD/Cycle,  although 
somewhat  less  intense. 
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AD/Cycle  Knowledge: 
Importance  and  Current  Satisfaction  of 
Vendors  and  IS  Departments 


Non-AD/Cycle  Application  Development  Products; 
Importance  and  Current  Knowledge  of 
Vendors  and  IS  Departments 


Vendors 
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^  Importance 
□  Knowledge 

_i  I 

5 

High 


0 1991  by  INPUT.  Reproduction  Prohibited. 


VI-3 


THE  FUTURE  OF  CASE:  1991-1996 


INPUT 


B  

Leading  CASE  Exhibit  VI-4  shows  the  leading  vendors  in  the  CASE  product  market. 

Product  Vendors 

These  companies  account  for  approximately  75%  of  the  market's  rev- 
enues in  1990. 


Leading  CASE  Vendors 
by  Estimated  1990  U.S.  CASE  Product  Sales 

•  KnowledgeWare 

•  Intersolv 

•  Texas  Instruments 

•  Cadre 

•  Pansophic 

•  Andersen  Consulting 

•  Oracle 

•  Synon 

•CGI 

•  Viasoft 

•  Transform  Logic 

•  DEC 

•  Interactive  Development  Environments 

•  Computer  Associates 

•  Manager 

•  Bach  man 

Note:  Excludes  real-time  tools,  debugging  tools,  project 
management,  4GLs,  decision  support,  report  writers 

KnowledgeWare  was  the  stellar  performer,  doubling  its  revenues  from 
1989  to  1990.  It  is  no  coincidence  that  KnowledgeWare  now  comes 
closest  to  "being"  AD/Cycle  (and  has  not  been  bashful  in  making  this 
known). 

IBM  itself  is  not  even  on  the  list  yet,  since  AD/Cycle  is,  so  far,  made  up 
almost  wholly  of  third-party  products.  Four  of  the  six  CASE  companies 
in  which  IBM  has  made  an  investment  are  on  the  list.  The  six  CASE- 
related  equity  partners  are: 
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•  KnowledgeWare 

•  Index  Technologies 

•  Synon 

•  Bachman  Information  Systems 

•  Systematica 

•  Easel  Corporation 

c  

CASE  Product  There  are  two  types  of  CASE  product  vendors  operating  in  the  current 

Vendor  Strategies         market:  hardware  vendors  and  independent  CASE  software  product 

companies  (although  with  IBM's  investments,  this  line  has  blurred 
somewhat).  This  section  will  examine  the  strategies  of  IBM  and  DEC 
and  then  examine  the  common  threads  in  the  strategies  of  the  indepen- 
dent vendors. 

1.  IBM 

In  the  changing  environment  of  the  1980s,  IBM  saw  its  hardware  sales 
growth  shrink  and  a  continued  erosion  in  overall  account  control.  The 
strategic  elements  in  its  CASE  initiative  can  potentially  provide  impetus 
for  IBM's  hardware  growth  and  account  control.  These  strategic  ele- 
ments include: 

•  Rapid  application  development 

•  Building  a  proprietary  CASE  environment 

•  Providing  CASE  product  options  to  customers 

•  Co-opting  potential  third-party  competitors 

•  Providing  CASE-based  applications  solutions 

See  Exhibit  VI-5  for  the  relationships  between  IBM's  objectives. 


EXHIBIT  VI-5 


IBM's  Intermediate  and  Final  CASE  Objectives 
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a.  Rapid  Application  Development 

This  is  the  technical  heart  of  CASE,  of  course.  The  faster  that  business- 
driven  applications  can  be  built,  the  more  hardware  is  needed — a  crude 
equation,  but  real.  However,  two  barriers  have  to  be  overcome: 

•  CASE  acceptance  and  related  culture  change  are  potential  bottlenecks. 

•  The  right  paths  to  CASE  development  are  still  difficult  to  find. 

Rapid  application  development  will  by  itself  contribute  only  marginally 
to  account  control  since  a  system  of  even  more  rapid  application  devel- 
opment could  displace  it. 

b.  De  Facto  Standard 

AD/Cycle  as  it  is  evolving  is  semi-open  in  respect  to  IBM's  sharing  of 
technical  information  and  adopting  outsiders'  suggestions.  However, 
IBM  controls  the  process.  While  copyright  and  trade  secrets  will  protect 
some  of  the  core  technical  knowledge,  the  sheer  bulk  of  AD/Cycle  will 
discourage  most  other  vendors  from  trying  to  duplicate  it.  This  could 
result  in  the  type  of  account  control  that  MVS  now  provides,  the  differ- 
ence being  that  customers  may  be  content  with  this  situation  if  they 
perceive  that  they  benefit  from  IBM's  dominance  of  CASE. 

INPUT  believes  AD/Cycle  will  gradually  produce  de  facto  methodology 
standards. 

•  The  front-end  tools  offered  by  IBM  and  its  equity  partners  will  be  more 
receptive  to  certain  methodologies  than  others. 

•  IBM  has  assigned  a  high  priority  to  its  own  consulting  and  professional 
services  activities.  By  the  end  of  1991,  virtually  all  of  IBM's  systems 
design-related  activities  will  be  utiUzing  as  many  parts  of  AD/Cycle  as 
are  feasible  in  a  particular  assignment.  IBM  is  very  likely  to  settle  on  a 
limited  number  of  methodological  approaches  in  its  own  use  of  AD/ 
Cycle. 

c.  CASE  Product  Options 

One  of  the  unique  features  of  the  AD/Cycle  strategy  is  its  incorporation 
of  other  vendors'  software  products  into  an  IBM  "product."  The  prod- 
ucts come  from  vendors  in  which  IBM  has  a  made  an  equity  investment. 
This  approach  provides  customer  benefits  that  will  reinforce  account 
control: 
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•  Customers  are  given  a  choice  of  products  that  are  essentially  compat- 
ible and  replaceable — but  all  are  under  IBM's  ultimate  control. 

•  There  will  be  internal  competition  among  the  partners  and  between 
them  and  IBM.  This  way  neither  IBM  nor  its  customers  are  locked  into 
a  single  technology  path. 

d.  Co-Option  of  Third  Parties 

Related  to  the  offering  of  AD/Cycle  product  options,  but  more  subtle  and 
more  powerful,  is  the  co-option  of  third  parties:  at  the  announcement  of 
AD/Cycle  IBM  also  announced  a  list  of  over  40  "development  associate" 
vendors  that  would  be  cooperating  with  IBM.  This  list  included  many 
potential  direct  competitors;  since  then  most  significant  CASE  product 
vendors  have  announced  that  they  will  be  compatible  with  AD/Cycle. 
Even  some  other  hardware  manufacturers  are  building  AD/Cycle  bridges 
into  their  CASE  planning. 

e.  CASE-Based  Application  Solutions 

Creating  applications  software  packages  on  top  of  AD/Cycle  is  a  very 
important  long-term  objective.  IBM's  investments  in  applications  soft- 
ware product  companies  (e.g.,  Policy  Management  Systems)  could  begin 
a  move  in  this  direction.  However,  IBM  will  rely  largely  on  the  market 
acceptance  of  AD/Cycle  to  convince  application  product  companies  to 
take  this  step.  If  AD/Cycle- based  packaged  software  reaches  critical 
mass,  both  hardware  sales  and  account  control  will  be  helped  signifi- 
cantiy. 

f.  Summary 

Exhibit  VI-6  summarizes  the  role  that  the  strategic  elements  of  CASE 
could  have  on  IBM's  business  objectives.  IBM's  strategy  is  a  broad- 
based  one:  not  every  element  has  to  achieve  its  maximum  potential  for 
IBM's  strategy  to  be  a  success  overall.  For  example,  even  if  IBM  lost 
part  of  its  proprietary  control  of  AD/Cycle,  its  overall  account  control 
strategy  could  still  succeed. 
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The  Role  of  CASE  in  Supporting 
IBIVl's  Business  Objectives 


Strategic  CASE  Elements 

Business  Objectives 

Account 
Control 

Hardware 
Sales 

CASE-based  applications  solutions 

H 

H 

Co-option  of  third  parties 

H 

M/H 

Rapid  application  development 

M/L 

H 

Proprietary  CASE  environment 

H 

L 

Provision  of  CASE  product  options 

M/H 

M 

Key:   H  =  High  importance  of  CASE  component 
M  =  Medium  importance 
L  =  Low  importance 


2.  DEC 

IBM  has  opted  for  a  CASE  environment  where  it  can  achieve  virtually 
total  control.  DEC  had  followed  this  same  path  in  the  late  1980s  as  it 
began  to  offer  an  increasingly  full  and  sophisticated  set  of  application 
building  tools.  It  was  natural  for  DEC  to  build  its  own  development 
software: 

•  The  same  type  of  strategic  considerations  which  impelled  IBM  to 
control  its  own  applications  development  environment  would  apply  to 
DEC  as  well,  although  with  slighUy  less  intensity. 

•  This  culminated  in  the  summer  of  1990  with  the  announcement  of  the 
future  direction  of  its  dictionary  product,  CDD+.  CDD+  was  an- 
nounced as  serving  as  the  basis  for  a  repository  architecture. 

•  At  the  same  time,  the  entire  concept  was  renamed  Cohesion.  Besides 
being  a  repository  product  functionally  analogous  with  AD/Cycle, 
Cohesion  would  ultimately  run  on  non-VAX  platforms  (UNIX,  OS/2, 
and  perhaps  others). 

However,  three  months  after  the  Cohesion  announcement,  DEC  an- 
nounced a  partnership  with  Texas  Instruments  whereby  the  TI  product, 
lEF,  would  be  ported  to  the  VAX  line.  In  early  1991,  DEC  made  a 
similar  announcement  regarding  Andersen  Consulting 's  Foundation 
product.  (See  Exhibit  VI-7.) 
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EXHIBIT  VI-7 


DEC'S  Overlapping  Strategies 


1980s 


Internally  Developed 
Tools 


lEF  (Texas 
Instruments) 


1990 


CDD+/Reposltory 
Architecture 


Cohesion 


Foundation 

(Andersen 

Consulting) 


1990s 


UNIX,  OS/2 
Platforms 


DEC  is  now  in  the  position  of  sponsoring  three  comprehensive  environ- 
ments for  its  VAX  platforms.  Those  from  its  partners  will  provide  multi- 
platform  connectivity  to  IBM  and  other  environments. 

•  This  kind  of  choice  will  give  VAX  customers  a  selection  of  CASE 
environments  to  work  in.  This  is  somewhat  similar  to  the  AD/Cycle 
philosophy. 

•  DEC  will  also  be  able  to  hedge  its  bets  on  the  ultimately  successful 
VAX-based  CASE  environment.  If  Cohesion  should  not  proceed  as 
expected  or  one  of  its  partners  falls  by  the  wayside,  DEC  would  still 
have  CASE-based  solutions  to  offer  its  core  market. 

•  It  is  also  possible  that  Cohesion  will  be  able  to  absorb  technology  from 
its  partners.  This  could  accelerate  Cohesion  development  and  also 
provide  greater  compatibility. 

However,  DEC  (and  its  customers)  do  run  risks  in  this  approach: 

•  The  main  risk  is  that  in  the  longer  run  DEC  will  not  be  perceived  as 
having  a  strategy.  Sponsoring  three  different  CASE  approaches  is 
something  that  no  other  vendor  has  attempted. 

•  CASE  integration  across  the  VAX  line  will  be  extremely  difficult 
because  DEC  will  not  be  sponsoring  a  de  facto  standard  like  IBM  has  in 
AD/Cycle.  DEC  may  be  underestimating  the  extent  to  which  its  cus- 
tomers require  an  AD/Cycle-like  approach. 
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•  DEC'S  partners  may  lose  interest  in  either  the  VAX  platform  or,  con- 
ceivably, CASE  itself.  For  both  TI  and  Andersen  Consulting,  their 
CASE  products  are  important  but  not  vital  to  the  firm's  continued  well- 
being.  In  any  event,  these  agreements  are  nonexclusive,  and  TI  and 
DEC  could  find  other  partners  that  could  prove  distracting. 

3.  ffiM  and  DEC  Strategies 

Both  IBM  and  DEC  have  taken  different  paths  in  traversing  from 
standalone  CASE  to  repository  CASE  (Exhibit  VI-8). 


IBM  and  DEC 
Overlapping  Strategies 


Third- Party 
Supplied 


Standalone 
CASE 


Linked 
CASE 


Repository 
CASE 


DEC 
1990 


Vendor 
Supplied 


DEC 
1985 


DEC 
1987 


?  <- 


.  ->  9 


•  IBM  initially  depended  entirely  on  the  third-party  community  for 
CASE  products.  This  position  has  now  changed  completely. 

•  DEC,  on  the  other  hand,  may  have  begun  the  opposite  journey.  How- 
ever, the  ultimate  basis  for  its  repository  is  still  not  clear. 
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4.  Independent  Vendors 

Until  recently,  most  independent  CASE  product  vendors  focused  on  the 
IBM  370  series  as  the  target  platform,  with  the  IBM  PC  as  the  develop- 
mental platform. 

•  AD/Cycle  changed  that;  those  receiving  the  consolation  prize  of  "Ven- 
dor Associate"  discovered  that  companies  in  which  IBM  made  an 
investment  ("equity  partner")  had  the  inside  track. 

•  As  in  the  case  of  TI  and  Andersen,  there  has  been  a  search  for  friendlier 
platforms.  UNIX  has  aroused  particular  interest. 

Exhibit  VI-9  provides  a  snapshot  of  CASE  vendor  groupings. 


EXHIBIT  VI-9 


CASE  Vendor  Groupings 


AD/Cycle 
Equity  Partner 

Mu/oyuic 
Vendor 
Associate 

DEC 
Partner 

DEC 
Compatibility 

UNIX 
Platform 

KnowledgeWare 

X 

X 

Intersolv 

X 

X 

X 

Texas  Instruments 

X 

X 

X 

X 

Cadre 

X 

X 

>^ 

Pansophic 

X 

Andersen 

X 

X 

X 

Oracle 

X 

? 

X 

X 

Synon 

X 

X 

CGI 

X 

X 

Vlasoft 

X 

Transform  Logic 

X 

DEC 

X 

X 

X 

Interactive  Dev. 
Environment 

X 

X 

Computer  Assoc. 

Manager 

X 

Bachman 

X 

X 
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•  Multiple  platform  offerings  may  be  more  attractive  to  independent 
vendors  compared  to  basing  offerings  solely  on  the  IBM  platform. 

•  Multiplatform  implementation  will  also  offer  a  capability  that  is  not 
now  a  feature  of  AD/Cycle. 

•  Mergers  and  acquisitions  provide  another  means  to  provide  additional 
capabilities.  Exhibit  VI- 10  shows  mergers  and  acquisitions  involving 
leading  product  vendors. 


EXHIBIT  VI-10 


Selected  CASE  Mergers  and  Acquisitions 

•  KnowledgeWare  (Database  Design  and  Tarkenton  Software) 

•  Intersolv 

•  Cadre  (Northwest  Instruments  and  MicroCase) 

•  Pansophic  (Telon  product) 

•  Transform  Logic/Nastec 

•  IBM  (minority  investments  in  KnowledgeWare,  Index 
Technology,  Synon,  and  Bachman  Information  Systems) 

p  

Other  Types  of  1.  Overview 

Vendors 

Most  commercial  CASE-connected  offerings  are  still  focused  on  CASE 
software  products  and  tools.  Exhibit  VI- 1 1  analyzes  the  offerings  of 
vendors  at  a  recent  CASE  conference  exhibition: 

•  The  vast  majority  of  vendors  were  selling  front-end  or  back-end  tools. 
(The  percentages  in  Exhibit  VI- 1 1  slightly  understate  the  proportion  of 
CASE  product  offerings,  since  some  exhibits  contained  products  from 
two  or  more  vendors.) 

•  Most  of  the  CASE-connected  services  involved  the  supplying  of  CASE 
product  implementation  and  installation  services.  Several  were  offer- 
ing re-engineering  services. 
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Offerings  of  CASE  Products  vs.  CASE  Services 

CASE  Products  and 
Services 

7%  /  Services 

( 

CASE 

Methodology 

\  79% 

CASE  Products  \. 

Source:  Analysis  of  62  vendors  at  a  1991  CASE  exhibition 

Looking  into  the  future,  the  focus  of  CASE  offerings  will  almost  cer- 
tainly change.  There  will  be  many  fewer  CASE  products  on  the  market: 


•  As  noted  earlier,  there  is  industry  consensus  that  the  number  of  CASE 
product  vendors  will  be  dropping  sharply. 

-  The  principal  technical  and  market  impetus  will  come  from  the  need 
for  integration. 

-  Financial  pressures  will  continue  to  mount  for  the  secondary  players 
as  their  revenues  plateau  and  investors  become  wary. 

2.  CASE  Support  Software 

INPUT  expects  that  niche  markets  will  develop  around  core  CASE 
product  offerings  to  fill  specialized  needs. 

•  This  will  be  analogous  to  the  current  market  for  DB2  support  tools. 

•  However,  it  is  important  to  note  that  it  took  several  years  for  very  many 
DB2  support  tools  of  consequence  to  appear.  Potential  tool  suppliers 
had  to  understand  DB2  and  the  needs  of  the  DB2  market,  obtain  financ- 
ing, and  then  produce  and  market  products. 
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•  INPUT  expects  a  similar  market  to  grow  up  around  AD/Cycle  (and 
possibly  some  of  the  other  products).  However,  following  the  analogy 
of  DB2,  such  tools  will  not  begin  to  appear  until  1992  to  1993. 

Potential  areas  for  such  support  include: 

•  Tightly  integrated  project  management 

•  "Snap-in"  methodology  modules 

•  Business  information  models  for  specific  processes  (using  object- 
oriented  techniques  to  the  extent  these  will  be  supported). 

3.  Application  Software 

IBM  has  stated  on  several  occasions  its  long-term  view  of  CASE  (i.e., 
AD/Cycle)  serving  as  the  foundation  for  third-party  software  products. 
The  potential  attractions  of  such  products  for  a  vendor's  internal  opera- 
tions are  significant: 

•  The  potential  benefits  from  AD/Cycle  are  just  as  large  for  commercial 
software  producers  as  they  are  for  corporate  application  developers. 

•  Even  more  important,  CASE  techniques  could  improve  product  modifi- 
cation and  maintenance. 

Attractiveness  to  customers  could  be  even  more  important: 

•  CASE-built  applications  software  products  could  be  tailored  to  the 
specific  needs  of  a  customer.  This  tailoring  would  make  packaged 
products  much  more  attractive: 

-  Currently  a  customer's  operations  must  often  conform  to  the  software 
product.  CASE-built  software  products  would  have  the  potential  to 
conform  to  the  customer's  way  of  doing  business. 

-  The  uniformity  of  current  packaged  software  makes  it  difficult  to 
provide  a  unique  competitive  edge.  CASE-built  products  should 
have  the  flexibility  to  permit  corporations  to  proceed  in  different 
strategic  directions  utilizing  a  nominally  standard  software  product. 

•  For  example,  some  large  customers  have  historically  bought  applica- 
tions packages  to  serve  as  a  framework  for  extensive  custom  modifica- 
tion. CASE-built  products  would  formalize  this  process  and  make  it 
viable  for  much  smaller  organizations  to  use. 
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Attractive  as  this  might  be  in  concept,  the  risks  are  not  insignificant: 

•  Making  such  a  conversion  would  be  a  tremendous  undertaking  for  an 
established  vendor  in  terms  of  time  and  dollars.  Until  the  CASE  tech- 
nology is  well  established,  there  is  also  some  technical  risk  involved. 

•  Established  vendors  would  be  faced  with  supporting  CASE  and  non- 
CASE  product  Unes  for  some  time. 

-  The  ultimate  switching  of  all  non-CASE  customers  to  the  CASE- 
based  environment  would  be  a  long-term  operation,  at  best. 

-  Some  customers  would  be  unwilling  or  unable  to  make  the 
changeover. 

-  Dual  support  would  negate  some  of  the  benefits  of  offering  CASE- 
based  products. 

-  In  principle,  some  of  the  lost  benefits  could  be  gained  back  by  using 
the  CASE-based  product  to  generate  the  standard  product;  however,  it 
is  not  clear  at  this  point  what  proportion  of  both  product  versions 
could  be  jointly  supported. 

•  New  vendors  (or  established  vendors  offering  new  products)  would  not 
have  these  dual  product  line  trade-offs  to  make.  However,  they  would 
have  the  same  funding  and  development  hurdles  to  surmount. 

Understandably,  vendors  will  be  cautious  in  this  area.  They  will  be 
doubly  cautious  with  the  recent  history  of  OS/2  before  them: 

•  Many  vendors  geared  up  to  develop  and  offer  OS/2-based  products 
upon  the  initial  announcement. 

•  The  risk  was  seen  as  reasonable,  given  OS/2's  undoubted  technical 
advantages  and  IBM's  backing. 

•  OS/2,  of  course,  has  not  taken  off.  The  early-adopter  vendors  have 
found  themselves  with  very  slow-selling  products. 

•  The  investment  in  CASE  products  is  at  least  an  order  of  magnitude 
larger  than  for  most  OS/2  products. 

Exhibit  VI- 12  shows  how  CASE-related  factors  are  currently  balanced 
between  the  positive  and  negative. 
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EXHIBIT  VI-12 


CASE-Related  Application  Software  Product  Issues 


Factors 

Positive 

Negative 

Product 

•  Quality 

•  Technical  risk 

•  iimeiiness 

•  1  ime  ana  aoiiar  resources 

•  Flexibility 

•  Dual  product  support  , 

Customer 

•  Higher  quality 

•  Acceptance  rate 

•  Tailoring  capabilities 

•  integration  plans 

Timing 

•  Tie-in  to  customer  CASE 

•  Too  early 

planning 

•  Too  late 

input's  research  has  confirmed  the  underdevelopment  of  this  general 
area  (Exhibit  VI-13): 

•  Both  vendors  and  IS  departments  see  this  issue  as  being  of  moderate 
importance  now. 

•  The  levels  of  knowledge  and  understanding  are  extremely  low. 

This  is  an  area  that  needs  more  research,  especially  on  how  CASE-built 
applications  fit  into  customers'  long-term  CASE  plans. 
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EXHIBIT  VM3 


Impact  of  CASE  on  Other  Software  Product  Vendors: 
Importance  and  Current  Knowledge  of 
Vendors  and  IS  Departments 


Vendors 


IS  Departments 


^  Importance 
13  Knowledge 

4 
High 


4.  Professional  Services/Systems  Integration  Firms:  CASE-Based 
Development  Services 

CASE  vendors  are  becoming  more  aware  of  the  importance  of  CASE  to 
professional  service/systems  integration  vendors,  but  they  find  their 
knowledge  of  options  limited  (Exhibit  VI- 14).  IS  departments  have  not 
yet  awakened  to  the  potential  importance  CASE  holds  for  them  in  combi- 
nation with  externally  supplied  professional  services. 

•  Professional  services  firms  and  systems  integrators  within  the  informa- 
tion services  industry  will  soon  have  to  make  a  series  of  strategic 
decisions  concerning  their  CASE  position.  These  decisions  are  similar 
to  those  facing  IS  departments;  however,  the  vendor  position  is  much 
more  highly  leveraged. 

-  The  correct  decision  on  the  position  of  CASE  will  bring  vendors 
larger  benefits. 

-  Incorrect  decisions  could  prove  disastrous.  This  is  because  a  higher 
proportion  of  vendor  work  is  new  business,  which  is  much  more 
CASE-sensitive  than  the  maintenance/modification  work  that  makes 
up  most  IS  department  work. 
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Impact  of  CASE  on  Professional  Services  and 
Systems  Integration  Vendors: 
Importance  and  Current  Knowledge 
of  Vendors  and  IS  Departments 


Vendors 


IS  Departments 


Importance 
El  Knowledge 


0 

Low 


4 

High 


Professional  service  firms  and  systems  integrators  [to  be  called  systems 
integrators  for  the  remainder  of  this  section  for  the  sake  of  brevity]  are 
faced  with  many  strategic  choices  in  regard  to  CASE 
(see  Exhibit  VI- 15). 

•  "Non-CASE  driven"  is  basically  business  as  usual;  this  is  consistent 
with  the  decentralized  structure  of  most  systems  integration  firms, 
giving  local  and  vertically  focused  managers  the  flexibility  they  need 
to  respond  to  market  needs.  However,  this  approach  runs  the  risk  of 
adjusting  too  slowly  to  major  changes  in  the  market  environment,  such 
as  CASE. 


•  The  CASE-driven  choices  are  not  simple  ones: 

-  Building  on  a  firm's  own  proprietary  tools  can  be  very  efficient  and 
certainly  provides  account  control.  However,  a  firm  may  end  up  in  a 
technical  blind  alley  or  be  bypassed  by  market  factors  over  which  it 
has  little  control  (such  as  AD/Cycle). 
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EXHIBIT  VI-15 


Professional  Services/Systems  Integration  Firms 

CASE  Alternatives 


Strategic  Choices 


-  The  other  extreme  is  what  might  be  termed  an  "Open  CASE"  strat- 
egy where  a  systems  integrator  will  work  with  many  CASE  vendors 
(although  the  list  may  be  limited  for  reasons  of  feasibility  and  techni- 
cal critical  mass). 

-  The  remaining  options  come  under  the  broad  heading  of  "partner- 
ship." These  can  range  from  loose  arrangements  that  are  only  one 
step  away  form  an  "Open  CASE"  approach  to  an  exclusive  arrange- 
ment with  a  single  vendor.  In  between  are  tighter,  multiple  partner- 
ship arrangements  that  have  a  formal  structure. 

As  Exhibit  VI- 16  shows,  there  are  multiple  positive  and  negative  aspects 
to  each  potential  partnering  arrangement  when  looked  at  from  the  stand- 
point of  the  systems  integrator.  The  major  trade-offs  involve: 
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•  The  trade-off  between  controlling  or  influencing  the  technical  direction 
of  a  CASE  product  and  becoming  overcommitted  to  a  suboptimal 
solution 

•  Having  a  close  relationship  with  a  partner  at  the  expense  of  being  hurt 
if  the  partner  should  change  direction  or  suffer  a  business  reverse 

Many  customers  will  in  the  future  have  a  much  higher  interest  in  systems 
integrators'  utilization  of  CASE.  By  the  same  token,  customer  plans  for 
and  use  of  CASE  will  be  at  least  as  important  to  systems  integrators. 

•  Where  a  systems  integrator  is  committed  to  one  CASE  tool  (or  a  small 
selection  of  CASE  tools),  will  the  customer  accept  the  commitment? 

•  If  several  systems  integrators  are  developing  applications  for  an  organi- 
zation but  are  using  different  CASE  tools,  will  the  customer  organiza- 
tion understand  the  long-term  implications? 

•  If  a  customer  corporation  has  adopted  a  particular  CASE  tool  approach, 
will  all  integrators  have  to  conform? 

•  How  feasible  will  it  be  to  retrofit  applications  built  by  a  systems  inte- 
grator with  CASE  tool  A,  to  the  new  standard  involving  CASE  tool  B? 

5,  Professional  Services/Systems  Integration  Firms:  Other  CASE- 
Related  Services 

As  discussed  in  the  prior  subsection,  most  analyses  of  systems  integration 
and  CASE  revolve  around  the  use  of  CASE  in  the  systems  development 
process  (including  the  re-engineering  component). 

However,  this  may  be  too  narrow  a  view  of  corporate  needs  in  connection 
with  CASE.  This  is  especially  true  in  view  of  the  large  number  of  "soft" 
CASE  problems  that  have  surfaced  in  IS  departments  (see  Exhibit  III- 10). 

It  is  fairly  obvious  that  there  are  needs  for  broader  scale  assistance  in 
"acclimating"  a  corporation  to  the  "organizational  readiness"  issues  (see 
Exhibit  V-2). 

However,  acclimatization  cannot  be  done  in  a  vacuum:  acclimatizing 
would  be  linked  to  a  broad  program  of  CASE-related  training.  Such 
training  would  include: 

•  Training  CASE  users  in  methodology  use 

•  Training  business  analysts 
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•  Comprehensive  training  in  interviewing  skills  (since  the  critical  ele- 
ments in  CASE  environments  will  shift  from  properly  solving  the 
systems  problem  to  properly  defining  the  systems  problem). 

An  even  broader,  but  legitimate  use  of  CASE  knowledge  and  technology 
is  in  business-related  consulting,  i.e.,  in  the  "upstream"  activities  that 
may  or  may  not  lead  to  systems  consulting.  The  kinds  of  activities  where 
CASE  techniques  could  be  appropriate  include: 

•  Analyses  of  business  practices,  process,  and  rules 

•  Strategic  audits,  evaluating  an  organization's  competitive  advantages 

•  Organizational  analysis  using  CASE  diagramming  and  relationship 
tools 

This  list  is  meant  to  be  illustrative,  not  exhaustive.  More  research  is 
needed  to  confirm  and  expand  this  list.  Exhibit  VI- 17  summarizes  the 
examples  provided. 


EXHIBIT  VI-17 


Examples  of  Additional  CASE-Reiated  Services 

CASE- Related  Training 

CASE  Acclimatization 

Metliodology  development  and 

Success  factor  analysis 

training 

IS-user  analysis 

Business  analyst  training 

Organizational  changes 

Interviewing  skills 

Cultural  readiness  analysis 

r 

CASE-Based  Techniques  for 

Business  Consulting 

Business  process  analysis 

Strategy  modeling 

Organizational  analysis 
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Conclusions  and 
Recommendations 


A  

Conclusions  CASE'S  promise  is  still  largely  in  the  future. 

•  The  vast  majority  of  large  organizations  are  using  CASE,  but  generally 
only  in  a  fragmentary  way. 

•  The  impact  of  CASE  and  its  effectiveness  is  rated  quite  low  so  far. 
The  principal  barriers  to  a  CASE  "breakthrough"  have  been: 

•  Non-integrated  CASE  tool  environments 

•  The  lack  of  organizational  readiness  to  exploit  the  CASE  technology 

Repository-based  CASE  tool  environments  (notably  AD/Cycle)  offer 
good  prospects  for  integration.  (That  is,  Stage  3  CASE  products,  as 
shown  in  Exhibit  IV-6.)  The  readiness  of  the  typical  organization  to  take 
full  advantage  of  even  the  first  generation  of  Stage  3  products  is  still  in 
doubt. 

input's  view  is  that  the  key  technical  issue  over  the  next  five  years  will 
be  re-engineering: 

•  It  is  reasonably  close  to  resolution  of  the  remaining  open  technical 
issues. 

•  When  fully  resolved,  re-engineering  will  offer  the  most  payback  for  the 
typical  IS  organization. 
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Distributed  application  development  is  also  an  important  technical  issue. 
However,  the  underlying  distributed  data  base  technology  is  still  not 
fully  fixed  or  defined.  Therefore,  CASE  for  building  distributed  applica- 
tions is  essentially  on  hold  until  the  more  basic  technology  issues  have 
been  addressed.  INPUT  does  not  expect  CASE  environments  for  distrib- 
uted application  development  to  be  available  before  the  mid-1990s. 

Currently,  at  least  100  vendors  offer  CASE  products.  For  several  years 
there  has  been  consensus  that  the  industry  would  have  to  consolidate.  In 
1990,  this  trend  became  evident  for  vendors  offering  products  primarily 
for  IBM  platforms: 

•  AD/Cycle  had  a  chilling  effect  on  most  competing  products,  as  many 
buyers  froze  their  plans  to  evaluate  AD/Cycle. 

•  Based  on  INPUT'S  research,  the  majority  of  new  purchasers  will  move 
toward  AD/Cycle. 

•  Undercapitalized  product  vendors  and/or  those  with  a  low  share  in  the 
IBM  market  will  be  faced  with  several  options,  including  one  or  more 
of  the  following: 

-  Merger 

-  Development  of  niche  products 

-  Conversion  to  a  professional  services  firm 

-  Migration  to  other  platforms 

INPUT  expects  the  vendor  shakeout  to  continue,  leaving  a  relatively 
small  number  of  vendors  that  will  offer  fully  functional  integrated  CASE 
products  on  the  major  platforms. 

Exhibit  Vn-1  summarizes  the  major  conclusions  described  above. 
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EXHIBIT  VII-1 


Summary  of  Conclusions 

•  CASE  still  in  "promise,"  not  delivery,  stage 

•  Major  barriers 

-  Integration 

"Organizational  readiness 

•  Re-engineenng:  Significant  progress  expected 

•  Distributed  application  development:  limited 
progress  expected 

•  AD/Cycle 

-Will  probably  meet  most  integration  needs 

-Will  accelerate  vendor  consolidation 

B 


Recommendations 


1.  CASE  Users 


Each  organization  that  expects  to  gain  CASE  benefits  will  have  to  make  a 
thoroughgoing  commitment  to  CASE.  Exhibit  VII-2  is  a  sample  of  the 
type  of  readiness  evaluation  that  should  be  conducted  in  order  to  make  an 
effective  commitment. 


The  most  important  concrete  output  from  this  kind  of  planning  exercise  is 
to  understand  the  applicability  of  general  CASE  success/failure  factors  to 
a  fuTii's  specific  environment. 

IS  departments  should  also  begin  the  preparation  required  for  re-engi- 
neering. 

•  IS  departments  should  evaluate  current  major  applications  in  the  con- 
text of  future  application  plans. 
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Organizational  Readiness  Evaluation 

•  Cultural/organizational  readiness 

-Applicability  of  factors  to  specific  organizational  setting 

-  IS/user  relationships 

-Assessment 

-  Development  of  action  plan 

•  Development  methodology 

-Assessment  of  current  needs  and  practices 

-Comparison  to  availability  methodologies 

-  Implementation 

•  Measurement 

-  Identification  of  application  development  metrics 

-Test  and  evaluation 

•  CASE  planning 

-Success/failure  factors  assessment 

-Applicability  to  specific  organizational  environment 

•  This  analysis  could  produce  one  of  a  wide  range  of  conclusions:  from  a 
few  changes  in  an  application  to  a  re-analysis  of  a  business  system. 

•  Between  these  extremes  are  applications  that  need  a  significant  amount 
of  change:  Some  may  be  reverse  engineered  and  others  may  be  re- 
used. 
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Selecting  the  reverse  engineering  or  re-use  option  will  depend  on  mul- 
tiple factors: 

•  The  extent  to  which  existing  hardware/software  platforms  are  going  to 
be  changed.  The  more  changes  involved,  the  more  likely  that  reverse- 
engineering  will  not  be  suitable. 

•  Loose  linkages  to  other  applications  will  make  reverse  engineering 
more  attractive. 

•  Intensive  end-user  design  involvement,  on  the  other  hand,  would  favor 
re-use. 

•  The  extent  to  which  an  organization  is  experienced  and  committed  to 
forward  engineering  and  repository  technology  would  favor  re-use. 

Exhibit  VI-3  summarizes  these  factors. 


Factors  Affecting  Choice  of 
Re-engineering  Options 


Re-engineering  Options 

Factor 

Reverse-engineered 
Application 

Re-used 
Application 

Hardware/Software 
Platform 

Unchanged 

Changed 

Host/Workstation 
Relationship 

Unchanged 

Changed 

Linkage  to  Other 
Applications 

Loose 

Tight 

End-User  Design 
Involvement 

Moderate 

Intensive 

Organizations' 

Repository 

Experience 

Low 

High 

Forward 

Engineering 

Experience 

Low 

High 
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The  result  of  this  analysis  will  help  determine  a  firm's  overall  re-engi- 
neering strategy,  its  tactics,  and  the  types  of  re-engineering  tools  that  will 
be  most  appropriate. 

2.  CASE  Product  Vendors 

The  chief  challenge  for  every  CASE  vendor  is  how  to  come  to  terms 
with  the  market  reality  of  AD/Cycle.  This  includes: 

•  Changes  or  modifications  to  prior  strategic  direction 

•  Technical  linkage  (or  non-linkage) 

•  Developing  a  niche  strategy 

Generally,  vendors  that  are  affected  (or  potentially  affected)  by  AD/ 
Cycle  can  choose  among  three  strategies: 

•  Erecting  a  "firewall"  between  their  product  and  AD/Cycle  (e.g.,  select- 
ing incompatible  architectures  and/or  platforms) 

•  Building  a  bridge  to  AD/Cycle 
Finding  a  niche  function  within  AD/Cycle 
Exhibit  VII-4  illustrates  these  strategies 


AD/Cycle  CASE  Vendor  Options 


Bridge 


Product  A 


AD/Cycle 


Product  B 


Niche 


I 


Product  C 


Firewall 
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In  addition,  product  vendors  should  also: 

•  Weigh  offerings  (or  extending  offerings)  in  professional  services 

•  Evaluate  which  platforms  should  be  given  priority  for  both  develop- 
ment and  operations 

•  Develop  a  partnering  strategy 

All  this  will  have  to  take  place  within  a  financial  environment  where 
investments  and  paybacks  will  have  to  be  carefully  balanced. 

In  the  medium  term,  CASE  product  vendors  with  an  adequate  installed 
base  can  continue  to  exploit  current  customers,  as  a  worst-case  strategy. 
This  means,  however,  that  understanding  success  and  failure  factors  for  a 
specific  customer  environment  can  be  at  least  as  important  as  the  techni- 
cal adequacy  of  the  underlying  CASE  product.  These  recommendations 
are  summarized  in  Exhibit  Vn-5. 


EXHIBIT  Vli-5 


CASE  Product  Vendor 

Recommendations 

•  AD/Cycle 

•  Professional  services 

•  Partnering 

•  Investment 

•  Exploit  installed  base 

3.  Applications  Software  Product  Vendors 

For  the  most  part  it  is  too  early  to  be  offering  CASE-built  products. 
However,  given  product  lead  times,  every  vendor  should  now  be  develop- 
ing two  interrelated  strategies. 

•  What  part  to  play  in  AD/Cycle 

•  How  useful — and  over  what  time  period — CASE-built  products  would 
be  to  their  particular  client  bases. 
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4e  Professional  Services/Systems  Integration  Firms 

The  timeframe  for  developing  a  CASE  strategy  for  professional  service 
firms  and  systems  integrations  is  far  shorter  than  it  is  for  applications 
software  vendors. 

•  Each  vendor  should  by  now  have  a  well-defined  CASE  strategy.  This 
need  not  be  a  publicly  announced  strategy;  however,  some  version  of 
the  strategy  must  be  communicated  to  customers  and  prospects. 

•  Each  CASE  strategy  will  grow  out  of  an  individual  firm's  market 
position  and  technical  capabilities. 

•  Each  firm  must  develop  a  specific  strategy  for  dealing  with  AD/Cycle. 
This  can  range  from  treating  AD/Cycle  on  an  ad-hoc  basis  to  making 
AD/Cycle  a  firm's  official  development  environment. 

•  Given  the  dynamic  nature  of  the  CASE  market,  professional  services/ 
systems  integration  vendors  should  also  adopt  one  or  more  fallback 
strategies. 
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IS  Management 
Questionnaire  (Mail) 


INPUT,  in  cooperation  with  POSPP,  is  conducting  an  assessment  of  a  number  of  key  IS  technology 
and  implementation  trends.  Included  are  LANs  and  servers,  image  processing,  applications  develop- 
ment, and  data  center  operations.  The  questionnaire  can  be  completed  by  the  corporate  IS  function 
for  its  activities  or  by  a  division-level  IS  group. 

Your  response  to  the  questions  below  will  provide  the  foundation  for  INPUT'S  annual  report  on  the 
state  of  the  information  systems  function.  INPUT  will  be  presenting  the  results  of  this  research  at  a 
future  meeting  to  which  you  will  be  invited. 

Your  participation  is  appreciated.  Please  mail  your  completed  questionnaire  by  November  9,  1990, 
to:  Ellen  Snoyer,  POSPP,  3230  Commander  Drive,  CarroIIton,  TX  75006. 


Demographics 

la.      What  is  your  position/tide? 


lb.      Which  of  the  following  describes  your  information  systems  organization? 
  Corporate  IS    Division  IS 

Ic.      Are  you  responsible  for  the  telecommunications  function?   Yes   No 

2.       In  which  of  the  following  industries  is  your  organization? 

 Discrete  Manufacturing   Insurance 

 Process  Manufacturing   Medical 

 Transportation   Education 

 Utilities   Services 

 Telecommunications   Federal  Government 


 Retail  Distribution   State  &  Local  Gov't. 

 Wholesale  Distribution   Consumer  &  Home 

 Banking  &  Finance   Other  (Specify) 

3.  What  is  the  revenue  of  your  organization? 

a.  Revenue  b.  Number  of  Employees 

 Over  $10  billion   Over  10,000 

 Over  $  1  billion   Over  5,000 

 Over  $500  million   Over  1 ,000 

 Over  $100  million   Over  500 

 Over  $50  million   Under  500 

 Under  $50  million 
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4a.      What  is  the  size  of  your  organization's  information  systems  expenditures? 

 Over  $500  million   Over  $100  million         _  Over  $50  million 

 Over  $10  million   Over  $5  million  Under  $5  million 

4b.      What  is  the  average  age  of  your  systems?   .  yrs. 

4c.      What  is  your  current  application  backlog?   yrs« 

4d.      How  is  information  systems  organized? 

  Centralized    Decentralized  .  Combination 

Technology  Trends  &  Issues 

5a.      Using  a  check  mark  (/),  indicate  the  status  of  each  of  the  following  technologies. 


New  Technology 

Status  of  Use 

In  Use 

Planned  -  1991 

Planned  -  1992 

LANs/Servers 

Image  Processing 

Cooperative  Processing 

Distributed  DBMS 

CASE 

Engineering 

Commercial 

AI/Expert  Systems 

Standalone 

Imbedded 

Voice/Data  Integration 

Wide- Area  Networks 

Municipal- Area  Networks 

Object-Oriented  Programming 

UNIX 

Engineering 

Commercial 

Systems  Application  Architecture 

Open  Systems 
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5b.      What  are  the  primary  inhibitors  to  iinplementing  new  information  technologies? 

(1)   

(2)  

(3)  .  

5c.      When  are  you  most  likely  to  address  a  new  technology? 

  Availability  of  a  new  technology 

  As  a  by-product  of  an  application  system  project 

  Other  (specify)  

LANs  &  Servers 

6a.      What  is  the  number  of  operational  LANs  within  your  organization?  

6b.      What  is  the  projected  number  of  operational  LANs? 

1991   1992^   1995  


7.       Using  a  check  mark       indicate  the  level  of  integration  between  these  LANs. 


Type  of  LAN  Interconnection 

Degree  of  LAN  Interconnection 

None 

Low 

Medium 

High 

LAN-to-LAN 

LAN-to-Server 

LAN-to-Midrange 

LAN-to-Mainframe 

LAN-to-WAN 

LAN-to-MAN 

8.       Who  has  responsibility  for  management  and  support  of  the  LAN  environment? 


 Corporate  IS   Division  IS   User 

9.       How  would  you  rate  the  use  of  LAN  technology  within  your  organization?  (Circle  one) 

Not  Effective   .  Very 

Effective  Effective 

1  2  3  4  5 


UIIS1 


©  1991  by  INPUT.  Reproduction  Prohibited. 


A-3 


THE  FUTURE  OF  CASE:  1991-1996 


INPUT 


10.      Using  a  check  mark  (/),  indicate  the  status  of  the  following  applications  and  tools  on  LANs 
within  your  organization. 


LAN  Applications 

In  Use 

Planned  -  1991 

Planned  -  1992 

PC  tools  (spreadsheet,  etc) 

Desktop  publishing 

Electronic  mail 

Mainframe  DBMS  queries 

Executive  Information  Systems 

Accounting 

Order  entry 

Sales  reporting 

Production  scheduling 

CAD/CAM 

CASE 

Other  (specify) 

Other  (specify) 

Image  Processing 

1 1.      What  is  the  status  of  image  processing  within  your  organization? 

 In  production   Considered  and  deferred 

 Prototype   Not  applicable 

 Planned  for  1991   Not  considered  to  date 

 .  Under  consideration 
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12.      Please  list  image  processing  applications  in  use  or  planned  and,  using  a  check  mark  (/), 
indicate  the  status  of  each. 


Image  Processing  Applications 

In  Use 

Planned  -  1991 

Planned  -  1992 

(Specify) 

(Specify) 

(Specify) 

(Specify) 

13.  What  are  the  three  most  critical  issues  in  image  processing,  based  on  your  experience 
to  date? 

(1)   

(2)   

(3)  

14.  Who  is  funding  the  image  processing  activity? 

  Information  Systems 

  Corporate  User  Department 

  Division/Business  Unit 

  Other  (specify) .  

15.  What  role(s)  are  vendors  playing  in  your  image  processing  program? 

  Software  Product  Provider 

  Hardware  Provider 

  Consultant 

  Systems  Development 

  Systems  Integration 

  Systems  Operation 

  None 


16.      How  would  you  rate  the  use  of  image  processing  technology  within  your  organization? 
(Circle  one) 

Not  Effective    '  Very 

Effective  Effective 

1  2  3  4  5  . 
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Applications  Development 

17a.     Please  rank  the  top  5  (from  1  to  5)  applications  development  issues  in  terms  of  their 
relative  importance  over  the  next  two  years. 

  CASE   Human  resource  availability 

_   Relational  DBMS   Funding 

 Distributed  DBMS  ____  Vendor  capabilities 

  Re-engineering  existing  applications   End-User  application  development 

Workstation-based  applications 


17b.    What  other  issues  are  critical  to  your  applications  development  program? 

(1)  

(2)  

(3)   


18a.    What  is  the  current  percentage  of  development  resources  allocated  to  the  following? 

 %  Maintenance   %  Enhancement   %  New  Development 

18b.    How  effective  are  your  efforts  to  control  application  maintenance  resource  consumption? 

Not  Effective  Very 

Effective  .  Effective 

1  2  3  4  5 

18c.    Please  indicate  which  of  the  following  approaches  you  have  used  to  control  application 
maintenance  resources. 

  Limited  resource  allocation    Set  up  maintenance-only  function 

  Assign  to  user    Contract  with  outside  vendor 


Re-engineering  of  applications    Recoding  products 

Replace  with  purchased  software  product 

Other  (specify)  

Other  (specify)  


19a.    Please  indicate  your  status  with  CASE  technology. 

  In  use    Prototype 

  Under  consideration    Considered  and  not  in  use 

  Not  being  considered 


19b.    If  in  use,  what  percent  of  your  development  staff  is  using  CASE  tools?   % 
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19c.    If  in  use,  are  CASE  tools  being  applied  to: 

  New  development    Re-engineering  existing  applications    Both 

19d.    What  are  the  three  most  critical  issues  with  CASE,  based  on  your  experience  to  date? 

(1)  

(2)   

(3)   

20.  If  you  are  using  CASE,  how  would  you  rate  its  effectiveness?  (Circle  one) 

Not  Effective  Very 

Effective  Effective 

1  2  3  4  5 

Data  Center  Management 

The  following  questions  address  the  trends  to  automate  mainframe  data  centers  and  to  use  systems 
operations  vendors  to  manage  those  centers. 

21.  Is  there  more  than  one  mainframe  data  center? 
  Yes    No 

22.  If  there  is  more  than  one  mainframe  data  center,  is  there  an  active  consolidation  effort  in 
process  or  planned? 

  In  process    Planned  for  1991 

  Not  planned    Considered  and  rejected  or  deferred 


23.      Using  a  check  mark  (/),  classify  your  current  mainframe  data  center  objectives  by  the 
following. 


Objective 

Planned  for  within  which  year 

1990 

1991 

1993 

1995 

Fully  Staffed  Operation 

Consolidation  of  Centers 

Dimmed-Lights  Operation 

Lights-Out  Operation 

Systems  Operations  Vendor 

1 
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24.      Using  a  check  mark  (/),  indicate  which  of  the  following  technologies  are  being  used  to 
manage  your  data  center(s). 


Data  Center  Management  Tools 

In  Use 

Planned  - 1991 

Planned  -  1992 

Network  Control  Tools 

AI/Expert  Systems 

Security  Control 

Console  Message  Supression 

Odier  (Specify) 

25.      Are  you  using  or  considering  using  a  vendor  to  provide  data  center  operations  and/or  network 
management? 


a.  Data  center  operation  b.  Network  management 

 Using   Using 

 Considering   .  Considering 

____  Considered  and  not  using   Considered  and  not  using 

 Have  not  considered   Have  not  considered 


26.      If  using  a  vendor  for  data  center  operations  or  network  management,  are  the  services  provided 
on-site  or  remotely? 

a.  Data  center  operation  b.  Network  management 

  On-site   On-site 

 Remote   Remote 


27.      If  using  a  vendor  for  data  center  operations,  who  owns  the  equipment? 
 Client   Vendor 


28.  Indicate  which  of  the  following  services  are  provided  by  your  systems  operations  vendor. 

Data  Center  Operations    Applications  Maintenance 

  Network  Management    Applications  Development 

29.  If  you  are  using  a  systems  operations  vendor,  how  would  you  rate  its  effectiveness? 
(Circle  one) 


Not  Effective  Very 

Effective  Effective 

1  2  3  4  5 
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1 

IS  Management  Questionnaire 
(Telephone) 


1.  What  is  the  approximate  size  of  your  company's  IS  systems  budget? 

 over  $500  milUon   over  $100  million   over  $50  million 

 over  $10  million   over  $5  million   under  $5  million 

2.  How  would  you  compare  the  support  from  vendors  of  new  technology  now  as  compared  to  their 
support  a  few  years  ago? 

 worse   a  little  better   a  lot  better 

 about  the  same   somewhat  better 

2a.     On  a  scale  of  1  to  5  with  1  representing  none,  what  effect  does  vendor  support  have  on  your 
acquisition  of  new  technology? 

1  2  3  4  5 

I  would  like  to  ask  a  few  questions  regarding  your  use  of  LANs. 

3.  How  many  operational  LANs  do  you  now  have?  

4.  How  many  will  you  add  next  year?  and  in  '92  ? 

5.  Is  your  implementation  of  LANs  the  result  of  user  pull  or  IS  push   Both  ? 

6.  What  is  the  primary  LAN  interconnection  in  your  organization? 
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7.  Is  your  IS  operation  centralized  .  decentralized   or  both? 

If  centralized,  go  to  question  7  a. 

7a.    Is  the  use  of  LANs  leading  you  to  a  decentralized  IS  operation?  Yes  No 

If  yes,  go  to  7b;  If  no,  go  to  7c. 

7b.    How  fast?  

7c.    Do  you  expect  them  to  do  so  in  the  future?  Yes   No 

If  yes,  go  to  7d. 

7d.    How  soon?  

8.  On  a  scale  of  1  to  5  with  1  representing  not  effective,  how  would  you  rate  the  use  of  LAN 
technology  within  your  company? 

1  2  3  4  5 

Now  I  would  like  to  ask  you  a  few  questions  about  optical  image  management. 

9.  What  is  the  status  of  image  processing  in  your  organization? 

 In  production   Considered  and  deferred 

 Prototype   Not  applicable 

 Under  consideration   Not  considered  to  date 

9a.    On  a  scale  of  1  to  5  with  1  representing  not  effective,  how  would  you  rate  the  use  of  image 
management  technology  within  your  company? 

1  2  3  4  5 

9b.    What  difficulties  did  you  have  implementing  your  system? 
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9c.    How  did  you  cost  justify  the  acquisition  of  the  system? 


10.  On  a  scale  of  1  to  5  with  1  representing  completely  unsatisfactory,  how  do  you  rate  your 
vendor's  role  in  implementation  and  support? 

1  2  3  4  5 

11.  What  does  the  term  multimedia  mean  to  you? 


12.  On  a  scale  of  1  to  5  with  1  representing  none,  what  impact  do  you  expect  it  to  have  on  your 
organization  within  the  next  few  years? 

1  2  3  4  5 

Next  I  would  like  to  ask  you  a  few  questions  about  CASE. 

13.  Are  you  using  CASE?  Yes  No      If  yes,  go  to  13a. 

13a.  Are  you  using  it  for  reverse  engineering?  Yes  No  If  yes,  go  to  13b. 

13b.  On  a  scale  of  1  to  5  with  1  representing  not  at  all  effective,  how  do  you  rate  reverse  engineering 
with  CASE? 

1  2  3  4  5 

If  yes  to  13,  go  to  13c. 

13c.  On  a  scale  of  1  to  5  with  1  representing  none,  what  impact  has  the  use  of  CASE  had  on 
maintenance  costs? 

1  2  3  4  5 
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Just  a  few  more  questions. 

14.    Are  you  familiar  with  object-oriented  programming?  Yes  No     If  yes,  go  to  14a. 

14a.  What  does  that  term  mean  to  you? 


15.    Are  you  using  OOP?  Yes  .  No        If  yes,  go  to  15a. 

15a.  How  are  you  using  it? 


16.    Are  you  an  IBM  shop?  Yes  No     If  yes,  go  to  16a. 

16a.  Will  SAA  have  a  significant  impact  on  your  IS  operations? 

 Yes  No 

If  yes,  what? 


16b.  When?  

If  no  to  16,  why  not? 
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17.  Are  you  using  UNIX?  Yes  No 

If  yes,  go  to  17a.  If  no,  go  to  18. 

17a.  On  Mainframes          Midrange   Workstations  

17b.  What  applications  are  you  running? 

 Engineering  Operations  Business 

1 8.  Do  you  expect  to  adopt  UNIX?  ^Yes   No 

If  yes,  go  to  18a. 

18a.  When?  

18b.  Will  you  use  it  on  Mainframes  Midrange  Workstations 

If  yes  on  18,  go  to  18c. 
18c.  What  applications  will  you  run  on  UNIX? 

 Engineering  Operations  Business 

If  no  to  18,  why  not? 


19.  Are  you  using  relational  data  base  management  systems?   Yes  No 

20.  Are  you  using  or  considering  distributed  data  bases?   Yes  No      If  yes,  go  to  20a. 

If  no  to  20,  goto  21. 

20a.  Have  you  experienced  difficulties  with  them?  Yes  No      If  yes  to  20a,  go  to  20b. 

20b.  What  difficulties? 
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21.    Why  not? 


Thank  you  for  your  cooperation.  I  will  send  you  a  summary  of  the  survey  results,  which  you  should 
receive  in  January. 
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Application  Development  Manager 
Questionnaire 


IS  Departments 
1. 


First,  I  would  like  for  you  to  briefly  describe  the  extent  of  CASE  activities  now  underway  in 
your  organization. 


2.      What  are  your  organization's  future  plans? 


3.      What  have  you  found  to  be  the  main  problems  in  maximizing  CASE'S  potential  in  your  organi- 
zation? 
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Both  IS  Departments  and  Vendors 

4.      Now  I  would  like  to  ask  you  about  some  specific  topics  that  we  are  considering  including  in  our 
service.  For  each  one,  please  tell  me  how  important  this  kind  of  information  is  to  you  and  how 
satisfied  you  are  with  your  current  information.  Feel  free  to  make  any  comments.  (Rate  impor- 
tance and  satisfaction  on  a  scale  of  1-5,  with  5  being  high.) 

Importance  Satisfaction  Comments 

Case  studies  of  CASE  successes,  with   ___   

analysis  of  reasons   

Case  studies  of  CASE  failures  (or  limited       

successes)  with  analysis  of  reasons 

An  analysis  of  CASE  critical  success       

factors,  based  on  the  experience  of   

over  200  companies 

How  application  design  and  capabilities     

change  due  to  CASE  technology   

CASE  impact  on  end-user  departments      

and  corporate  strategy   

CASE  impact  on  packaged  software      

products  and  vendors   

CASE  impact  on  professional  services       

vendors  and  systems  integrators 

An  analysis  of  CASE  vendors,  their       

strategies  and  viability   

AD/Cycle  capabilities  and  future  direction       

Analyses  of  other  CASE  products?      

(Which?) 

CASE  market  size  and  growth  (broken      

out  by  product  type,  platform, 
customer  type,  etc.) 

CASE  standards       


Re-engineering 
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Distributed  systems  development 
Other  technical  issues  (describe) 
Other  (describe) 


5.      What  sources  do  you  use  to  supply  your  CASE  information  needs?  Please  be  as  specific  as 
possible,  including  how  well  they  meet  your  needs.  (Use  list  below  as  prompts,  if  necessary) 

«  Seminars/Conferences 

•  In-house  education 

•  Consultants 

•  Subscription  services 

•  General  publications,  books 

•  Informal  information  from  peers 


6.      Do  you  have  any  other  questions  and  comments? 
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1  a/ 

1  1 

CASE  Vendor  Questionnaire 


Vendors 

1.      What  CASE-related  products  and  services  do  you  now  offer? 


2.      How  receptive  have  you  found  the  market  generally  for  CASE-oriented  products  and  services? 
Why? 


3.      What  future  plans  do  you  have  (that  are  non-proprietary)? 


Both  IS  Departmetns  and  Vendors 

4.      Now  I  would  like  to  ask  you  about  some  specific  topics  that  we  are  considering  including  in  our 
service.  For  each  one,  please  tell  me  how  important  this  kind  of  information  is  to  you  and  how 
satisfied  you  are  with  your  current  information.  Feel  free  to  make  any  comments.  (Rate  impor- 
tance and  satisfaction  on  a  scale  of  1-5,  with  5  being  high.) 
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Importance    Satisfaction  Comments 

Case  studies  of  CASE  successes,  with       

analysis  of  reasons   

Case  studies  of  CASE  failures  (or  limited  _____     

successes)  with  analysis  of  reasons 

An  analysis  of  CASE  critical  success       

factors,  based  on  the  experience  of 
over  200  companies 

How  application  design  and  capabilities       

change  due  to  CASE  technology   

CASE  impact  on  end-user  departments       

and  corporate  strategy   

CASE  impact  on  packaged  software       

products  and  vendors   

CASE  impact  on  professional  services       

vendors  and  systems  integrators 

An  analysis  of  CASE  vendors,  their       

strategies  and  viability   

AD/Cycle  capabilities  and  future  direction       

Analyses  of  other  CASE  products?       

(Which?) 

CASE  market  size  and  growth  (broken       

out  by  product  type,  platform, 
customer  type,  etc.) 

CASE  standards  '       


Re-engineering 

Distributed  systems  development 
Other  technical  issues  (describe) 
Other  (describe) 
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What  sources  do  you  use  to  supply  your  CASE  information  needs?  Please  be  as  specific  as 
possible,  including  how  well  they  meet  your  needs.  (Use  list  below  as  prompts,  if  necessary) 

•  Seminars/conferences 

•  In-house  education 

•  Consultants 

•  Subscription  services 

•  General  publications,  books 

•  Informal  information  from  peers 


Do  you  have  any  other  questions  and  comments? 
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Type  of  Development  by 
Application  Focus :  1991 


EXHIBIT  E-1 


Application  Focus 


Type  of  Development 

Host-based 

Host-led 

Multiple 
Peer 

Total 

New  Development 

20 

16 

4 

40 

Enhancements 

15 

3 

2 

20 

Maintenance 

37 

2 

1 

40 

Total 

72 

21 

7 

100 

Source:  INPUT  estimates 
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Type  of  Development  by 
Application  Focus:  1996 


EXHIBIT  F-1 


Application  Focus 


Type  of  Development 

Host-based 

Host-led 

Multiple 
Peer 

Total 

New  Development 

5 

5 

15 

25 

New  Development 

via  Re-used  Applications 

15 

14 

1 

30 

Maintenance  via 
Reverse-engineered 

15 

5 

0 

20 

Traditional  Maintenance 

20 

4 

1 

25 

Total 

55 

28 

18 

100 

Source:  INPUT  estimates 
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Report  Quality  Evaluation 

To  our  clients: 

To  ensure  that  the  highest  standards  of  report  quality  are  maintained,  INPUT  would  appreciate  your  assessment  of 
this  report.  Please  take  a  moment  to  provide  your  evaluation  of  the  usefulness  and  quality  of  this  study  When 
complete,  simply  fold,  staple,  and  drop  in  the  mail.  Postage  has  been  pre-paid  by  INPUT  if  mailed  in  the  U.S. 

Thanlijyou. 

1.  Report  title:  r/)e  Fi/ft/re  0/ C>1SE;    1991-1996  {UIIS1) 

2.  Please  indicate  your  reason  for  reading  this  report: 

□  Required  reading  □  New  product  development       □  Future  purchase  decision 

□  Area  of  high  interest  □  Business/market  planning       □  Systems  planning 

□  Area  of  general  interest       □  Product  planning  □  Other  


3.  Please  indicate  extent  report  used  and  overall  usefulness: 

Extent                Usefulness  (1=Low,  5=High) 
Read      Skimmed            1        2       3       4  5 
Executive  Overview  □  □  □  □  □  □ 

Complete  report  □  □  □  □  □ 

Part  of  report  (  %)  □  □  □  □  □  □  □ 

4.  How  useful  were: 

Data  presented   □  n  □  □  □ 

Analyses  □  □  □  □  □ 

Recommendations  □  □  □  □  □ 

5.  How  useful  was  the  report  in  these  areas: 

Alert  you  to  new  opportunities  or  approaches...  □  □  □  □ 

Cover  new  areas  not  covered  elsewhere  □  □  □  □  □ 

Confirm  existing  ideas  □  □  □  □ 

Meet  expectations  □  .......  ........  ....... 

Other   ........  .......   □  □ 

6.  Which  topics  in  the  report  were  the  most  useful?  Why?   


7.     In  what  ways  could  the  report  have  been  improved? 


8.     Other  comments  or  suggestions: 
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